howdy all

ut oh i am understanding how a xul document works on an nsIDocument level tho it also means i know how they gut xul for xhtml not that they did it but how and why on a technical level and no it isnt anymore justified in my view also understand the content/ merge too ugh that muddies how the code works

i am a bit excited i am reading mozilla cpp and while some cppness is currently beyond me I have never read the code and gained this much insight past some function names

before

I should have tried to kill html5 10 years ago .. if that was all it would have taken LOL

now the gates are open .. i can't NOT learn it all now

I actually do like how nsDocument and various *Document bits are setup it is very classical mozilla very xpcom.. except for almost everything being shoved into HTMLDocument that is.. but that WAS the design but of course when that was written it used the full power of nsParser for html as well..

the content/ to dom/ merge did make it more complicated to work out.. but I traced it using the cross-reference to its former tree location and code state and that illuminated a lot.. This is why I have all those trees not just current dev and mozilla ;)

the damned mozilla tree structure WAS layed out to be as self describing as an XML document.. once

nsITobin hi

nsITobin disabled scriptcache writing in the last wip. errors are gone and I don't see much of a satartup regression if any.

still not sure what causes it with BigInt enabled

something for later.

yeah so.. I am gonna recommend NOT disolving XULDocument into HTMLDocument and other places.. it does require giving up templates xbl and overlays.. because well can't let the web have them and certainly can't have that many special cases it distracts from our special case glued in parser

that is what the code tells me not the bugs.. the code

don't care about rdf and xbl can go if replaceable but overlays is a different story.

Anyway sidebar and help would need to be rewritten so not happening in this life probably.

rdf is needed for templates

yes

i don't see the maintaince burdon for XBL OR RDF ..

or XUL as a distinct document type

xbl and shadow dom were a problem but solveable hopefully. PaleMoon still has it

it was a problem Mozilla solved just long enough to do the transition

UXP just solved it in a similar way just with my express directive that XBL must NOT be affected

likely some threat of extermination and such you know how I was.

Don't think we want shadow dom in chrome code so if only usable in web code all good.

I don't know if there is any way to prevent it

without expressly doing so

I'd basically make the pref to enable/disable webcomponents (Custom Elements/ShadowDOM) also check if XULXBL (some condition in there) also and just treat it as disabled for XUL or XBL documents

I think if it is inert and not used in xul xbl might be ok

I would say for any XML document but technically the officially unofficial xhtml5 would still need webcomponents

frg_Away: that is proven by UXP.. no one has ATTEMPTED to use webcomponents in xul so no one knows what will happen..

but not using it doesn't cause any issues lol

usually I am all for objects and encapulation but this is some really murky stuff which just feels unclean and like a hack.

one of the last directives I gave to the Add-ons Team was to push back on someone using webcomponents in xul if it happened until we knew more.. same with most html5 related technologies regardless if they seemed to work..

Maybe I should revise my recommendation to don't merge xul with xhtml unless you are gonna pull the tigger on it all and then regroup in xhtml-xul-webcomponents land.

I am not as opposed to xhtml merge as I was a year ago I just think a few more checks and we could keep the special xulness and extend it to xhtml processed in a chrome context ..

so effectively in quantum XUL is an XML Namespace in an xhtml identified but xml parsed HTMLDocument where as right now it is a XULDocument.. XULDocument already has specialized code for chrome privs and protocol checks for chrome and about protocols.. etc those checks and XUL's XULness could be merged in as well it would just be more complicated and yeah gross but its all gross so whatev at this point

xhtml on the web would be xhtml .. xhtml in chrome would be xhtml plus more extensive xul handling

The third option between Mozilla and UXP lol

potentally

That is one thing that is so disappointing about Mozilla.. most everything they have done HAS potental even stuff that I or we may find kinda silly considering other things.. even those things have potental but this html5 quest .. it just sucks the potental out of everything

frg_Away: however don't forget there is a solution for overlays as a jsm/esmodule

central needs to be made more operational .. there are too many unknowns and not enough people to fork an intermitiary codebase which would also be a huge unknown cause of the era

reverse logic back to figure out what all the options are and mistakes to avoid

tomman: Status Report on the CloudFlare Siege, please :P

no data, coming back from a blackout

are you and everyone ok?

but I suspect today will be a day of no news

nah, outages are the new normal here~

> TypeError: k[l] is undefined

that's also the new normal :D

TypeError.. that sounds like its assuming my type..

how dare it

do that in Java and your program will burst in flames, crash the economy, kill someone, and cause Larry Ellison to sue youi

--you

do that in JS and... well, "complain to the Customer Service department, but all our lines are busy"

in other news, Hackernews flip-flops lately between "We're having some trouble serving your request. Sorry! " and just a plaintext "Sorry."

being Y Combinator's pet project is suffering

gitlab 2.53 updated

fun

I am gonna switch ftp over to php control today see if that doesn't break for hours for some small stupid thing lol so ftp may be down today seafiles web access won't be affected

ftp auth

gitlab wip updated

:)

frg_Away: know why I like qimport? because it basically does what I wrote a script to do on the git side .. read and apply patches from the web or elsewhere

yes basically eats everything and applies it

it was a pain in the ass

qimport just does exactly the same thing and I have a nice patch file as well

mess with it sort it out whatever .. why would anyone not want this

nsITobin did you try git am?. That is how I usually apply the patches to git.

yeah i never understood git am

only time i used it was experimentally to bust basilisk off from UXP while preserving history of the application but not surrounding UXP tree

I am a bonified COMM-Engineer lol

ue it to apply the patches for releases: gitlab.com/frg/seamonkey-253-patche…al/applypatchescr.sh?ref_type=heads

^Use it

if I had the time and drive to do so I'd convert UXP into a patchqueue ontop of 52.6 but 3way merges make that a fuckin tedious excersize in futility especially once webcomponents starts landing.. g4jc did make a mess

works well

... IF I HAD KNOW...

known*

for really any git conversion to hg if you ever did a merge really you can only go forward not backward

if there are no 3 way merges then well you can convert a repo then put just about the entire history into the patchqueue

which is REALLY cool

there is one thing I don't get though.. something like an rpm is a source tarball with patches on top.. patch files i don't think qualify as "the prefered form for making changes to source" or phrasing to that effect.. so how can fedora redhat others ship just source tarball and an automated patch system and that alone satisfies the MPL in terms of the executable form distributed.. I wonder if that will ever be tested... Cause I think it is an MPL

violation if you do not provide the exact source used not the pieces to the exact source and not third party or upstream links.. Of course SeaMonkey satisifes this with tarballs and also the git repo.. but yeah I don't think patch files + tarball is enough for the MPL

rest well frg