mozilla :: #content

17 Jul 2017
16:54bytesizedcatalinb: How are things looking on https://bugzilla.mozilla.org/show_bug.cgi?id=651120 ? I just got back from PTO and I am trying to figure out if I should work on 1377219 now or put it off a bit longer.
16:54firebotBug 651120 NEW, catalin.badea392@gmail.com Remove DOM node child array storage
18:15bzHmm. Why do we have XULLabeledControlElement classinfo?
18:17* bz starts strongly suspecting this is dead code
18:18bzoh, maybe so we can define window.XULControlElement....
18:24bzsmaug: ping
18:40bzpeterv, smaug: is anyone actively working on https://bugzilla.mozilla.org/show_bug.cgi?id=888600 ?
18:40firebotBug 888600 ASSIGNED, peterv@propagandism.org Move ContentFrameMessageManager to WebIDL
18:40bzpeterv, smaug: or should I feel free to steal it?
18:41bzpeterv, smaug: and are there partial patches floating about somewhere?
18:41smaugbz: pong
18:41smaughmm, I'm not actively looking that code
18:42smaugand don't know if peterv has patches
18:42bzok
18:42* bz will try to get hold of peterv
18:42bzThe message managers are the only thing left with domclassinfo, basically
19:02bytesizedcatalinb: reping ^
19:03smaugbz: yeah, sorry about that
19:06bzsmaug: it's not a problem
19:06bzsmaug: just trying to look for nice relaxing things to do when I get tired of wrestling with hard bits. ;)
19:06bzwell, nice relaxing useful things. ;)
19:24catalinbbytesized: hi
19:25catalinbbytesized: I'm still working on the nsRange change I was telling you about. bug 1380367
19:25firebothttps://bugzil.la/1380367 NEW, catalin.badea392@gmail.com Use node references for range boundaries in nsRange
19:26bytesizedcatalinb: So it sounds like I should work on something else while I am waiting for 651120 to merge.
19:26bytesizedsound good?
19:26catalinbbytesized: yes
19:27bytesizedcool, thanks
20:36smaugwhaat is this
20:36smaug"you do not have permissions to modify files under servo/"
20:36smaugemilio: ping
20:37emiliosmaug: wanna land the extended slots thing?
20:37smaugyes
20:37smaugI had r=heycam
20:37smaugis that not enough?
20:37emiliosmaug: That needs to go through a pr to github.com/servo/servo
20:37emiliosmaug: I can write it and land it real quick
20:37smaugthat makes no sense
20:37emiliosmaug: you tell me...
20:37smaugemilio: the patch can't land if the gecko patch doesn't land too
20:38smaugand gecko patch must land to m-i
20:38emiliosmaug: yeah, but the servo patch can land straight away in m/c
20:38emilioerr
20:38emiliosmaug: in autoland
20:38smaugor autoland
20:38emiliosmaug: does it need to be m-i instead of autoland?
20:38emiliosmaug: oh, ok
20:38smaugautoland is fine
20:38smaugbut ok, I will never ever write changes which affect stylo
20:39emiliosmaug: yeah, the usual procedure is landing the servo bit first because servo CI is slow... It's kind of a pain to patches that affect only the Gecko side of things...
20:39emiliosmaug: can you send me the updated patch?
20:39smaugemilio: patches are in the bug
20:40emiliosmaug: ok, will land that and ping you
20:40smaugemilio: are there plans to fix this setup. This is totally not ok
20:40emiliosmaug: feel free to ping the build people or bobby about the annoyance I guess :)
20:53emiliosmaug: should I go ahead and land https://github.com/servo/servo/pull/17758?
20:53emiliosmaug: I can land the Gecko patch to autoland as soon as it lands
20:53emiliosmaug: sorry for the inconvenience again, I agree this setup is extremely stupid for this kind of changes
20:54smaugyeah, I will just not deal with stylo ever again
20:54smaugunless this setup is fixed
20:54smaugstylo work really must not break common gecko workflows
20:54smaugemilio: but thanks
20:55smaugnot your fault ;)
20:55smaugbut I will not care about the bug anymore
20:55smaugs/will/do/
20:56emiliosmaug: yeah, sorry... I'll take care of landing it (and address the trailing whitespace issue)
20:56emiliosmaug: it's this thing where landing stuff directly to inbound/autoland on the servo/ dir may break servo's CI... Of course that in your case is moot, because you're changing only Gecko code
20:57emiliosmaug: I think I have an idea to improve the workflow for this kind of changes that don't involve touching style system code
20:57emiliosmaug: I'll file a bug for that
21:03emiliosmaug: filed bug 1381629
21:03firebothttps://bugzil.la/1381629 NEW, nobody@mozilla.org stylo: Improve the workflow for landing patches that don't touch style system code like bug 1377993
21:04emiliosmaug: what commit message do you want the Gecko-side patch to have? Same as the bug title?
21:07smaugwhatever
21:07* smaug is rather p***ed ***
21:12emiliosmaug: I understand, sorry :(
21:12smaugnot your fault!
21:13emilioYeah, but I can feel why it is so annoying, and I would hate it
21:37smaug( it is rather surprising that someone who thought to be a core DOM developer can't anymore land patches which are supposed to touch only core DOM implementation. )
23:19smaugbz: remind me about our QI in JS and webidl. Can we have element implementations which don't actually QI to some nsIDOM* interface, but yet the JS QI would succeed?
23:20smaugor perhaps we could use some tearoffs? Just thinking if we could shrink the size of some commonly used elements by not inheriting nsIDOM* yet not break existing chrome/addon JS code
23:51mccr8nice, xpcIJSModuleLoader is scriptable, so addons could in theory implement their own module loaders.
23:54mccr8oh right, that just means it is usable from JS. phew.
23:55mccr8well, but it isn't builtinclass so the same thing applies.
18 Jul 2017
No messages
   
Last message: 66 days and 8 hours ago