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