11:17:38 <IanN> howdy all
12:51:37 <Tobin-webirc> 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
13:24:17 <nsITobin> 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
13:24:28 <nsITobin> before
13:25:28 <nsITobin> I should have tried to kill html5 10 years ago .. if that was all it would have taken LOL
13:25:47 <nsITobin> now the gates are open .. i can't NOT learn it all now
13:32:18 <nsITobin> 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..
13:34:02 <nsITobin> 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 ;)
13:35:14 <nsITobin> the damned mozilla tree structure WAS layed out to be as self describing as an XML document.. once
13:37:50 <frg_Away> nsITobin hi
13:38:37 <frg_Away> nsITobin disabled scriptcache writing in the last wip. errors are gone and I don't see much of a satartup regression if any.
13:39:04 <frg_Away> still not sure what causes it with BigInt enabled
13:39:15 <frg_Away> something for later.
13:41:28 <nsITobin> 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
13:42:10 <nsITobin> that is what the code tells me not the bugs.. the code
13:42:59 <frg_Away> don't care about rdf and xbl can go if replaceable but overlays is a different story.
13:43:40 <frg_Away> Anyway sidebar and help would need to be rewritten so not happening in this life probably.
13:43:51 <nsITobin> rdf is needed for templates
13:44:38 <frg_Away> yes
13:44:58 <nsITobin> i don't see the maintaince burdon for XBL OR RDF ..
13:45:07 <nsITobin> or XUL as a distinct document type
13:46:17 <frg_Away> xbl and shadow dom were a problem but solveable hopefully. PaleMoon still has it
13:47:09 <nsITobin> it was a problem Mozilla solved just long enough to do the transition
13:49:27 <nsITobin> UXP just solved it in a similar way just with my express directive that XBL must NOT be affected
13:49:44 <nsITobin> likely some threat of extermination and such you know how I was.
13:50:00 <frg_Away> Don't think we want shadow dom in chrome code so if only usable in web code all good.
13:50:23 <nsITobin> I don't know if there is any way to prevent it
13:50:31 <nsITobin> without expressly doing so
13:52:45 <nsITobin> 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
13:54:13 <frg_Away> I think if it is inert and not used in xul xbl might be ok
13:54:16 <nsITobin> I would say for any XML document but technically the officially unofficial xhtml5 would still need webcomponents
13:54:45 <nsITobin> frg_Away: that is proven by UXP.. no one has ATTEMPTED to use webcomponents in xul so no one knows what will happen..
13:55:01 <nsITobin> but not using it doesn't cause any issues lol
13:55:59 <frg_Away> usually I am all for objects and encapulation but this is some really murky stuff which just feels unclean and like a hack.
13:56:38 <nsITobin> 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..
14:00:45 <nsITobin> 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.
14:03:07 <nsITobin> 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 ..
14:04:59 <nsITobin> 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
14:05:50 <nsITobin> xhtml on the web would be xhtml .. xhtml in chrome would be xhtml plus more extensive xul handling
14:06:18 <nsITobin> The third option between Mozilla and UXP lol
14:06:25 <nsITobin> potentally
14:10:47 <nsITobin> 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
14:32:35 <nsITobin> frg_Away: however don't forget there is a solution for overlays as a jsm/esmodule
14:41:25 <nsITobin> 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
14:42:13 <nsITobin> reverse logic back to figure out what all the options are and mistakes to avoid
14:43:48 <nsITobin> tomman: Status Report on the CloudFlare Siege, please :P
14:44:02 <tomman> no data, coming back from a blackout
14:44:12 <nsITobin> are you and everyone ok?
14:44:16 <tomman> but I suspect today will be a day of no news
14:44:26 <tomman> nah, outages are the new normal here~
14:45:05 <tomman> > TypeError: k[l] is undefined
14:45:08 <tomman> that's also the new normal :D
14:45:30 <nsITobin> TypeError.. that sounds like its assuming my type..
14:45:32 <nsITobin> how dare it
14:46:38 <tomman> do that in Java and your program will burst in flames, crash the economy, kill someone, and cause Larry Ellison to sue youi
14:46:41 <tomman> --you
14:47:04 <tomman> do that in JS and... well, "complain to the Customer Service department, but all our lines are busy"
15:00:13 <tomman> in other news, Hackernews flip-flops lately between "We're having some trouble serving your request. Sorry! " and just a plaintext "Sorry."
15:00:53 <tomman> being Y Combinator's pet project is suffering
15:07:35 <frg_Away> gitlab 2.53 updated
15:09:03 <nsITobin> fun
15:12:49 <nsITobin> 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
15:13:26 <nsITobin> ftp auth
22:15:50 <frg_Away> gitlab wip updated
22:53:11 <nsITobin> :)
22:55:17 <nsITobin> 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
22:56:08 <frg_Away> yes basically eats everything and applies it
22:59:25 <nsITobin> https://dpaste.org/AQQ6m
22:59:37 <nsITobin> it was a pain in the ass
22:59:57 <nsITobin> qimport just does exactly the same thing and I have a nice patch file as well
23:00:24 <nsITobin> mess with it sort it out whatever .. why would anyone not want this
23:05:50 <frg_Away> nsITobin did you try git am?. That is how I usually apply the patches to git.
23:21:35 <nsITobin> yeah i never understood git am
23:22:11 <nsITobin> only time i used it was experimentally to bust basilisk off from UXP while preserving history of the application but not surrounding UXP tree
23:22:27 <nsITobin> I am a bonified COMM-Engineer lol
23:23:50 <frg_Away> ue it to apply the patches for releases: https://gitlab.com/frg/seamonkey-253-patches/-/blob/master/scripts/scripts-for-official/applypatchescr.sh?ref_type=heads
23:24:06 <frg_Away> ^Use it
23:24:09 <nsITobin> 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
23:24:12 <frg_Away> works well
23:24:46 <nsITobin> ... IF I HAD KNOW...
23:24:57 <nsITobin> known*
23:26:33 <nsITobin> for really any git conversion to hg if you ever did a merge really you can only go forward not backward
23:27:03 <nsITobin> if there are no 3 way merges then well you can convert a repo then put just about the entire history into the patchqueue
23:27:06 <nsITobin> which is REALLY cool
23:32:41 <nsITobin> 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
23:32:41 <nsITobin> 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
23:42:24 <nsITobin> rest well frg