mozilla :: #content

7 Sep 2017
00:46bkellyasuth: I think I might try doing a very lame parent-side intercept... there are just too many races in the e10s redirect code
00:51jdmorly
00:52bkellyjdm: or more likely I'm just not smart enough to understand it all
00:56bkellyjdm: current thing I can't understand is why on redirect we do a ChannelConnect, but then also AsyncOpen on the channel after the redirect completes?
00:56jdmbkelly: I suspect you're missing the Send__delete__ that happens immediately
00:56bkellyjdm: the intent is that will kill the connected channel and then we re-open it?
00:56jdmafter recvredirect3complete or something?
00:56jdmyes
00:57bkellywell, in my modified code that is very racy... because sometimes the underlying parent channel gets an OnStartRequest in before the send__delete__ can stop it
00:57bkellyI could slow down the parent side... but I'm worried that would just be papering over a problem for tests
00:58bkellyjdm: and it appears that send__delete__ doesn't happen immediately any more.. we do a SendFinishInterceptedRedirect() ping/pong before we do it... its during that ping/pong time that my OnStartRequest sneaks in
00:59bkellysometimes it sneaks in
00:59jdmbleah
00:59bkellyjdm: which triggers the "in practice" part of this comment: http://searchfox.org/mozilla-central/source/netwerk/protocol/http/HttpChannelChild.cpp#669
01:10bkellyI guess I can paper over the problem for the short term
01:10bkellyor maybe suspend the channel until RecvFinishInterceptedRedirect is received
01:20* jdm can't remember if he ever thought of suspending the channel
01:35bkellyasuth: ok... immediate crisis averted
01:35bkellythe suspend thing seems to work
02:00asuthqDot: pong
07:00bakuqDot: pong?
07:01qDotbaku: Hey! I was just wondering about your comment on bug 1388125. Is that something that might be doable before 57? I could possibly try and help out if needed.
07:01firebothttps://bugzil.la/1388125 NEW, nobody@mozilla.org Video elements with URL Object srcs pointing to large video files can hang content process on MediaC
07:01bakuqDot: I have a green try push \o/ for my IPCBlob async stuff. so, finger-crossed, yes. I'll work on that today.
07:02bakuqDot: I mean, on that bug.
07:03qDotbaku: Awesome, thanks! Yeah the lag on that is just awful and I was kinda surprised when the media team blamed it on the mediacache. Figured we shouldn't be hitting the cache at all heh.
07:05bakuqDot: I think we just don't have tests for that scenario.
07:05bakuBlobs created by contents are fast as always. But remote blobs, yeah, we need to change a couple of things to make them fast as before.
07:46bakuannevk: ping, do you know why OffscreenCanvas inherits EventTarget? It seems an error to me: https://html.spec.whatwg.org/multipage/canvas.html#the-offscreencanvas-interface
07:51annevkbaku: no, file an issue?
07:51bakudoing
07:51bakuannevk: 3017
07:51annevkbaku: I can't find any event dispatching prose so definitely seems wrong somehow
07:51annevkbaku: ta
09:47jgrahambkelly: Not sure. We are setting things up so that a crash in a child process is fatal, but I don't know how the stack reporting stuff works
11:50smaugfreesamael: thanks for looking that popstate bug
12:36petervjib: in my pastebin from yesterday I was missing a Cu.unwaiveXrays around entry when setting the _isRemote property
13:49bkellysmaug: do you see speedometer improvements with the fix in bug https://bugzilla.mozilla.org/show_bug.cgi?id=1377131?
13:49firebotBug 1377131 FIXED, bugs@pettay.fi Try to trigger collector slices at times which disturb page js less (at least with iframes loaded af
13:50smaugbkelly: locally I do on this machine
13:50smaugit used to be more, but now maybe < 1 point (old points)
13:51bkellywoah... I just saw a multi-second pause in AWFY on my local machine
13:51bkellynot AWFY... running speedometer locally
13:52bkellystill got a good score, though... hmm
13:52smaugbkelly: network issue?
13:52smaugI get multi-second pauses often when running it on the reference laptop at the summer place where network connection is rather bad
13:54bkellysmaug: ran it again and didn&#39;t get a pause... worse score... wonder if the pause gave GC/CC time to run, etc
13:54smaugexactly :)
13:55smaugthe more idle time we have, the less GC/CC/SnowWhite disturb the test
13:58smaugbkelly: my gut feeling is that most of the optimizations we need to do are in JS engine
13:58smaugwe behave quite well for example in vanillajs
13:59bkellysmaug: the fact that we are further behind chrome on the slower machine does suggest our CPU efficiency is worse... which would be consistent with needing improvements in js engine
14:01smaugbkelly: since you&#39;re there and have windows machine, want to test https://bug1347525.bmoattachments.org/attachment.cgi?id=8847585
14:01firebothttps://bugzil.la/1347525 FIXED, nobody@mozilla.org Setting innerHTML slower than in Chrome
14:01smaugNightly vs Chrome
14:02bkellysmaug: nightly gives me 30 and chrome gives me 50
14:03smaugok, similar-ish to linux, thanks
14:03smaugThat is a case where we did improve quite well, and most of the fixes have been really small ones.
14:05bkellycool
14:10freesamaelsmaug: np. not many bugs I can help with recently, if you find something I might be able to help with, let me know :)
14:16smaugfreesamael: &quot;fix the session history handling in the HTML spec and figure out how session history should work in shadow DOM&quot; :)
14:18freesamaellol
14:19freesamaeloh shadow DOM could be an interesting topic. I have no idea how it works...
14:21smaugfreesamael: rniwa said a year ago he would implement a plan we discussed at TPAC, but I don&#39;t think that ever happened. And it didn&#39;t get recorded in https://github.com/w3c/webcomponents/issues/184
14:21smaugI, rniwa, kochi and hayato were at that meeting
14:25freesamaelsmaug: not quite related but do we have any special handling for sandboxed iframe? I&#39;ve been curious about that before.
14:26freesamaeloh there&#39;s a reference bug at the bottom
14:26smaugI think we don&#39;t have.
14:26smaugyeah
14:27freesamaeland I have subscribed the sandboxed iframe bug before... lol
14:35freesamaelsmaug: are you available for some other questions now? when fixing test cases I found a test case using SpecialPowers.executeSoon(generator.next), and when the generator function gets called in this way, I found ScriptSettingsStack only include TabChildGlobal, but not the nsGlobalWindow for the test cases itself.
14:36freesamaelso my question is why ScriptSettingsStack::Top() wouldn&#39;t be the nsGlobalWindow of the test case?
14:36smauginteresting, and unexpected
14:36smaugdo you have link to some example code?
14:36smaughmm
14:36smaugSpecialPowers does live in TabChildGlobal
14:38freesamaelsmaug: yes it&#39;s in the removing removing browser.sessionhistory.cache_subframe patch
14:38freesamaelhttps://reviewboard.mozilla.org/r/176356/#review181242
14:38smaugfreesamael: yeah, I guess nothing pushes the globalwindow to stack there. It is just TabChildGlobal executing something
14:39freesamaelbut wouldn&#39;t the ... incumbent global being the nsGlobalWindow? the exact breakpoint I used was at the &quot;testWin.location = windowRelativeURL;&quot; below
14:40freesamaelI thought at that point Top() would be the test case
14:41freesamaelI noticed that because the assignment wouldn&#39;t able to get correct base URI to compose location with a relative path
14:45freesamaelI rr recored it, checked the entryGlobal, and found the stack doesn&#39;t contain nsGlobalWindow at all
16:07bkellyasuth: can you sanity check me on something?
16:08bkellyasuth: this test tries to do a synthetic redirect, to another synthetic redirect, to a real file: http://searchfox.org/mozilla-central/source/dom/workers/test/serviceworkers/fetch_event_worker.js#52
16:08bkellyasuth: woops... thats the service worker bits... the test is here: http://searchfox.org/mozilla-central/source/dom/workers/test/serviceworkers/fetch/fetch_tests.js#70
16:09bkellyasuth: but I don&#39;t think this should work per the spec, since an XHR uses a follow redirect mode and step 4.2 here says to start bypassing the service worker if the mode is follow: https://fetch.spec.whatwg.org/#http-fetch
16:09bkellyasuth: my new intercepted channel starts making us fail this test... and I think that is correct... what do you think?
16:24annevksounds correct, redirects only cause re-entry with navigation
16:25bkellyannevk: thanks
16:26annevkHmm, now I wonder though if that&#39;s sufficient to exploit things :/
16:27asuthI think we do the right thing if things bounce out of the origin though, right?
16:28annevkOooh no, the reason navigation is safe is because the request is not exposed to the same service worker
16:28annevkI hope I don&#39;t have to think through that every six months and can just assume at some point things are okay
16:29asuthpicking the serviceworker comes from the docshell
16:30asuthoh, hm
17:13jgrahambkelly: You might be interested in https://pastebin.mozilla.org/9031705 Assuming my script is right, it&#39;s the number of times a file in one of those directories under testing/web-platform/tests/ has been touched by a change to m-c since the start of the year (a single commit touching N files in the same directory counts N). Should exclude upstream imports and backouts/relandings (but using a pretty dody
17:14jgrahamheuristic for the latter)
17:14jgraham*dodgy
17:14jgrahamfoolip had similar numbers for Chrome and they have higher &quot;scores&quot; for e.g. html, dom
18:06bkellyannevk: asuth: oh, I think I am wrong... step 4.2 here only triggers if the service worker does *not* provide a response with respondWith(): https://fetch.spec.whatwg.org/#http-fetch
18:10asuthbkelly: I had punted on looking at the test after anne responded when I got back to keys; should I look at the test (and page in redirect knowledge)?
18:11bkellyasuth: I&#39;m not sure... the test is basically intercept 1 -> synthesize redirect to same scope -> intercept 2 -> synthesize redirect to out of scope -> real redirect
18:12bkellywe should probably a WPT for this
18:13annevkbkelly: oh right, there&#39;s even a note
18:14annevkbkelly: however, opaqueredirect results in a network error if redirect mode is follow
18:14bkellyannevk: correct
18:14annevkbkelly: but synthetic redirects are indeed ok
18:14bkellyannevk: but Response.redirect(url) does not produce an opaqueredirect
18:14bkellyright
18:14annevkYup, okay, sorry for the confusion
18:15bkellyannevk: lack of WPT tests here is worrying
18:16bkellyjgraham: was are you trying to measure with that data?
18:17jgrahambkelly: Get some rough metric of where we are contributing to wpt
18:17bkellyjgraham: that ignores contributions to upstream directly?
18:17jgrahambkelly: Yes
18:19bkellyjgraham: lower numbers could also indicate less activity changing dom/html code in general
18:19jgrahamYep, it could be related to relatively lots of perf work and little feature work for example
18:20jgrahamI might try to get similar numbers for changes to mochitest, although obviously it wouldn&#39;t be grouped in exactly the same way
19:18smaugjgraham: does that count changes to .ini too?
19:18smaugI assume no
19:18smaugthere is feature work happening where we do rely on the existing tests
19:18smauglike custom elements
19:19smaug(also many patches pending, will land after 57 branching )
19:56jgrahamsmaug: Yeah, specifically excluding ini changes
19:57jgrahamThe question is more like &quot;how much are we contributing to wpt&quot; not &quot;how much are we using existing wpt tests&quot;
19:57smaugright
19:58smaugyeah, I think in dom/base and dom/html we&#39;ve just been doing such feature work which Chrome has already done, I guess.
20:10bkellyasuth: overholt: ok... now I am swinging back to &quot;burn it all down&quot;
20:11asuthbkelly: is that the project name? &quot;Quantum Burn It All Down&quot;?
20:15bkellynow I think I&#39;m hitting a crash that doesn&#39;t even trigger service workers
20:21bkellyI guess it triggers child process reset interception... but not the code I touched
20:21* bz hates AutoJSContext so much....
20:22* bkelly hates a lot of things these days...
20:26* bkelly notices crashes go away when he removes printf statements.
20:26* bkelly is not amused.
20:33smaugmccr8: hmm, I wonder if I should look into HTMLInputElement ownership
20:33smaugcan be tricky
20:33smaugbut 20% of those QIs is coming from there
20:33smaugno, wait, 30%
20:33mccr8smaug: yeah that was really surprising to me, that they were showing up in the profiles.
20:34smaugit is just tricky to maintain
20:34smaugthe canskip/content blasting optimization
20:34smaugOwnedOnlyByTheDOMTree works only in simple cases
20:35mccr8Quantum Burn would be a pretty sweet name for a cyberpunk novel.
20:40mccr8smaug: do you still see stacks with CC stuff in them? In ehsan&#39;s old profile, there was stuff like nsStyledElement::QI being called from CCGraphBuilder::NoteXPCOMChild.
20:40mccr8That&#39;s what I was really interested in.
20:42smaughmm, I closed the window, but the one I was looking at was traversing some nodes which had a pointer to an HTMLInputElement
20:42smauglet me reprofile
20:42mccr8yeah I saw the input element stuff before but I think it wasn&#39;t directly CC related
20:42mccr8also nsTextNode was in the CC
20:43mccr8then form and input stuff that wasn&#39;t in the CC
20:45smaugmccr8: ok, so now I see HTMLInputElement being QIied in GetOwnedFrameSelection
20:47smaugyeah, nsTextControlFrame does lots of QIing
20:48mccr8smaug: well, if you don&#39;t see any CC QI, we can close the bug.
20:48smaugmccr8: that is possible, but I don&#39;t fully trust this profiling
20:49mccr8fair enough. We can just wait then.
20:49smaugI mean, results vary
20:49mccr8I think we&#39;ve fixed most of it.
20:49mccr8Sure.
20:49mccr8Ehsan&#39;s two prior profiles were pretty consistent.
20:50ehsanmccr8, (I have made an opt build to respond to your needinfo btw, but I&#39;m technically already on PTO!)
20:50ehsanI may still do it today though, if not, I&#39;ll do it on Tuesday
20:51mccr8ehsan: there&#39;s no hurry!
23:43billmjdm: ping?
23:44jdmbillm: pong
23:45billmjdm: hi, do you have a second to answer a question about cookies and bug 1331680?
23:45firebothttps://bugzil.la/1331680 FIXED, amchung@mozilla.com Consider not doing sync IPC for document.cookie getter/setter
23:45jdmbillm: sure
23:46billmjdm: I&#39;ve been doing some testing of using multiple queues for the different TabGroups and SystemGroup for the Quantum DOM stuff, and I&#39;m seeing a test failure in cookie code
23:46billmjdm: I&#39;m wondering if there&#39;s an ordering issue with how cookies are sent down
23:47billmjdm: when and how do cookies get sent down to the child process if it requests a document with a Set-Cookie HTTP header?
23:48jdmbillm: when the parent channel&#39;s OnStartRequest for the document runs, the cookie service sends all cookies that the document can access to the child process before the OnStartRequest IPC message
23:49billmjdm: what message does it use to send them?
23:50billmjdm: is it just AddCookie?
23:51billmor is it TrackCookieLoad?
23:51jdmbillm: PrepareCookieList
23:51billmjdm: wait, doesn&#39;t that go to the parent?
23:53jdmwhoops, misread the patch
23:54jdmbillm: TrackCookiesLoad
23:55billmjdm: ok, cool. thanks. I think I understand the problem. I&#39;ll follow-up in a bug with you. need to head home now.
23:55* jdm looks forward to it
8 Sep 2017
No messages
   
Last message: 13 days and 18 hours ago