mozilla :: #content

16 May 2017
00:04bkellythe thing where nightly just stops painting windows for one content process really sucks
00:04bkellysecond time I have hit it today
01:52bkellymccr8: turns out there was an extra Unused << refPtr.forget() in there
01:52bkellyremoving that fixed my leak
04:31gandalfdo we know why is our module loading 9 times slower than safari&#39;s?
13:07zer0what we&#39;re using nowadays to debug a firefox debug build on osx? Do we have a mdn page with some instructions?
13:18padenotzer0, lldb
13:19zer0padenot, thanks; I found a post about lldb but whas dated 2014 so I wasn&#39;t sure if it was still that. Thanks a lot!
13:22zer0just in case, anyone familiar with: ? Specifically about the two condition where NS_ERROR_UNEXPECTED is thrown, apparently it happens on one simple and specific web page when is loaded and I&#39;m still not sure why.
13:42* bkelly continues to tilt against AbstractThread windmills...
13:42* bkelly could be confused about that saying...
14:09catalinbinteresting naming choice
14:17bzcatalinb: Very descriptive
15:48bobowenbz: ping
15:50bzbobowen: in a meeting, sorry
15:50bobowenbz: OK, it was just a review nag :-)
15:51bzsorry. :(
15:51bzIn meetings till 12:30, then planning to do review
15:51* bobowen would have been surprised if it were just one
16:01smaugcatalinb: yeah, so unfair. peterv (IIRC) managed to get r+ for BlastSubtreeToPieces, but I couldn&#39;t land ContentBlaster :)
16:10bzsmaug: Did you ask me to review ContentBlaster?
16:10* bz sees no problem with it.
16:16petervbz: so I&#39;m looking at the XUL DOMCI stuff, for the CanCreateWrapper hack, I should check for IsContentXBLScope and then try to QI the object to the two interfaces that we want to allow still?
16:16petervnsITreeSelection and nsIDOMXULCommandDispatcher
16:17bzpeterv: I&#39;m in a meeting for another 10-15 mins
16:17smaugbz: no, jst
16:17bzpeterv: Do you mind if I think about this after?
16:17petervbz: no, no problem, I might be away but I&#39;ll see the reply
16:17petervbz: unless you prefer I put stuff in the bug?
16:18bzpeterv: great, thanks
16:18bzpeterv: putting stuff in the bug works too, and lets other see it as needed
16:18bzpeterv: So I&#39;d be totally fine with that
16:27bzpeterv: OK, with you
16:27bzpeterv: so this is about ?
16:27firebotBug 1252211 ASSIGNED, Convert remaining XUL DOM classes to WebIDL
16:29bzpeterv: QI to the interfaces seems plausible. We could also check the IID probably; I dunno that anyone is passing these through nsISupports and expecting them to work in content xbl
16:29bzpetterv: QI would obviously be more compatible
17:24bzwpt now has tooling to run all four major engines on pull requests
17:32bzer, wrong window
17:51mystorbz: That is pretty snazzy
17:58bzmystor: which?
17:58bzmystor: btw... how do you feel about reviewing ?
17:59firebotBug 1217238 ASSIGNED, Reduce precision of time exposed by Javascript (Tor 1517)
17:59mystorbz: The wpt having tooling to run all four major engines on pull requests
17:59bzmystor: Ah. Yeah, it&#39;s neat.
17:59mystorbz: And I can look at it
18:00mystorbz: Not super familiar with JS code
18:00bzIt&#39;s almost all dom/workers changes, fwiw
18:00bzAnd then lots of dom/ bits
18:00mystorkk, makes sense
18:01bzThe js/ parts you can ask someone on the JS team to review; I would have done that anyway
18:01mystorSounds good
18:02bzFwiw, one of the things that I&#39;d been having concerns with in those patches was the whack-a-moliness
18:02bzBut I didn&#39;t have time to come up with constructive suggestions
18:02bzSo if you have the same issue and do, feel free to. ;)
18:10bzbobowen: done, and sorry again for the lag
18:14bobowenbz: no problem and thanks, I did it that way so I didn&#39;t have to deal with the session restore bits :-)
18:15bobowenbz: I started adding a remote type to the history and almost got the session restore working, but then decided it wasn&#39;t worth the hassle
18:16bobowenbz: it was mainly complicated by the fact that we send all the session history up to the parent all the time
18:17mystorbz: Yeah, I don&#39;t really have any ideas off of the top of my head
18:22bzmystor: ok
18:34mystorbz: Do you know what the reason is why they went with a new javascript.options.privacy.resistFingerprinting pref instead of just using the existing privacy.resistFingerprinting pref?
18:34mystorbz: Is there some reason related to the JS engine wanting to remain separate?
18:37bzmystor: we have some machinery for automatically handling javascript.options.* preferences in some places
18:37bzmystor: but past that, I&#39;m not sure there&#39;s a good reason for it.
18:37bzmystor: (in that we observe that whole branch, but we also observe other things too....)
18:37mystorbz: mk
19:17mystorI&#39;m trying to printf() some stuff for testing on windows (in an opt build) and it seems to me like the output text is just being gobbled up. Do we eat up windows standard out?
19:27jugglinmike1bkelly: another day, another test
19:28jugglinmike1This time, I&#39;m looking at an extension that you authored which isn&#39;t available in Chromium&#39;s version
19:28bzmystor: it goes to the windows console, not the terminal
19:28mystorbz: Where is that?
19:28bkellyjugglinmike1: ok
19:28bzmystor: firefox -console, iirc
19:28* mystor obviously understands windows
19:29jugglinmike1I think this doesn&#39;t go far enough :) What do you say we wait until the &quot;good&quot; worker reaches the &quot;installed&quot; state?
19:29bobowenmystor: is it from the content process?
19:29bzoh, right, and that only works for the chrome process
19:29bzThe content process, you&#39;re out of luck
19:29bobowenmystor: redirect to a file if it is
19:29bzOh, huh
19:29* bz didn&#39;t know that worked
19:29bobowenmystor: known issue with the sandbox
19:30mystorbobowen: goodie
19:30mystorbz: I was hoping to get output from bothj
19:30bobowenbz: I use &quot;... &> whatever.log&quot;
19:30* mystor just wanted to be able to watch a log to see when things happen while running
19:31mystorbobowen: So `mach run &> whatever.log` and then `tail -f whatever.log` in another process?
19:31bobowenmystor: well I use a tail addin for vim but that should work
19:32mystorawespme, thanks
19:32bobowenmystor: I tend to use printf_stderr, but I think it should work for stdout as well
19:33bobowenmystor: I haven&#39;t had time to look into the long standing problem with the sandbox, but chrome has the same issue, so I suspect it&#39;s not easy to fix :-)
20:05bkellyjugglinmike1: I guess that would be fine, but since only one job can be running at a time it should not be necessary
20:05jugglinmike1bkelly: got it
20:05bkellyjugglinmike1: actually... you are right... installing is before the install job starts
20:05bkellyerr no
20:05bkellyregister job can&#39;t run until the previous job completes
20:05jugglinmike1but now I&#39;m trying to understand why Chromium fails here
20:06jugglinmike1In Chromium, the &quot;bad&quot; worker is made redundant by the good one
20:06bkellyjugglinmike1: I think my first statement was correct... the register job should not start until the previous job completes... when means the register should be blocked and not get to installing until previous job completes
20:06bkellyjugglinmike1: chrome probably implements the original spec
20:06jugglinmike1Conceptually, I think that make sense. But I can&#39;t find the language that supports that
20:07jugglinmike1According to the spec, it seems like the &quot;bad&quot; worker should kind of go into limbo, as far as the registration is concerned
20:08jugglinmike1i.e. the &quot;good&quot; worker for that scope should pass through &quot;install&quot; into &quot;active&quot;, and as a result, the registration&#39;s &quot;installing&quot; worker would be null
20:08bkellyjugglinmike1: register() queues a job:
20:08bkellystep 6 here:
20:08bkellythen step 12 here:
20:09bkellyschedule job waits for the previous job to compelte:
20:10bkellyjobs that install don&#39;t finish their job until after the install event is resolved... step 19 here:
20:10bkellyjugglinmike1: does that make sense? ^^^
20:10bkellyjugglinmike1: sorry, I have to go cut the grass
20:10jugglinmike1oh, I love that smell
20:10bkellyjugglinmike1: you&#39;re welcome to come over and do it!
20:11jugglinmike1Haha, I have a father of my own thank you very much
20:19jugglinmike1bkelly: I think this test might be over-loaded
20:19jugglinmike1(I know you&#39;re mowing; I&#39;ll explain for when you get back)
20:21jugglinmike1when it comes to testing that &quot;waitUntil&quot; halts the progression through the lifecycle events, I think we&#39;re covered by this:
20:22jugglinmike1but I don&#39;t think that means this test we&#39;ve been discussing can be removed completely. This test uses a different strategy to verify that, and Chrome fails it
20:22jugglinmike1I think that we should rename this to something like `register-task-queue` and delete the second half
20:24jugglinmike1Even if we don&#39;t change the test code itself, the file and description needs to be changed because after your patch, it no longer waits &quot;forever&quot;. But I do think it would be better to separate concerns, provided you agree the second half is duplicative of `extendable-event-waituntill.https.html`
20:25jstsmaug: sorry to have been such a party pooper wrt naming things :)
20:26jstI blame Sprocket
21:09smaugmccr8: yeah, noticed
21:09smaugmccr8: I wonder...
21:09mccr8smaug: I didn&#39;t look too closely but I think those methods might be identical by the end, in the various subclasses
21:10smaugmccr8: does the patch end up changing black roots
21:11smaug doesn&#39;t go through all the MessageManager globals
21:12smaugoh, maybe it does
22:47billmfroydnj: ping?
17 May 2017
No messages
Last message: 94 days and 3 hours ago