mozilla :: #e10s

16 May 2017
15:31snorpanyone know how nsIBrowserDOMWindow is used (or rather, isn't?) in an e10s window?
15:31snorpwhat's the right thing to implement for controlling window open behavior?
15:33snorpmconley: ^^^
15:34mconleysnorp: hey
15:34mconleyfor e10s windows, I believe nsIBrowserDOMWindow is used whenever ContentParent decides that a content process has requested a new tab rather than a new window
15:35mconleyhttp://searchfox.org/mozilla-central/source/dom/ipc/ContentParent.cpp#4549-4570
15:36mconley^-- this will, for example, interpret a message from the content process to open a new window as "oh, we'd better open a new tab in the current window instead"
15:36snorpah, hmm
15:37snorpI'm doing target=_blank and not getting a nsIBrowserDOMWindow path
15:37snorpso I guess I need to debug what's going on there
15:37snorpmconley: thanks
15:37mconleysnorp: np
15:43bkellydoes fennec not support --run-until-failure when doing ./mach mochitest some/test/path?
15:47* snorp shrugs
15:49bkellyoops... wrong channel
16:04elanhttps://bugzilla.mozilla.org/show_bug.cgi?id=1362493
16:04firebotBug 1362493 FIXED, mrbkap@mozilla.com e10s beta cohort distribution improvements
16:06mrbkapelan: when did the latest Beta build go out?
16:06mrbkap(how many days have those users been telemetry-ing?)
16:07elanit hasn't gone out yet
16:07elansorry, I meant it landed
16:07elanand should ship today
16:08mrbkapelan: ok, so that's why the addons-*-multiBucket* don't appear yet, cool.
16:10elansorry, I'll clarify that
16:21snorpmconley: hmm, so I'm setting the browserDOMWindow but it doesn't get passed down to the tab parent, which is where content parent gets it from?
16:21snorprace?
16:23snorplooks like frame loader gets it from window and sets it on tab parent
16:23snorpbut somehow that happens before I set it on the window
17:17shellis this what we'd use for multi comments as well?
17:18shellsorry, is this e10s list a good place for multi questions as well
17:24elanyes
17:24elanshell: all the things
17:29shellthe slightly higher content crashes for web extension/multi crashes in beta... Release Management is asking to uplift a patch (bug 1358879) that may improve the bug we saw correlation with. so if that goes, hopefully we can see improvements in stability in those 2 cohorts. will track and update at Fri meeting.
17:29firebothttps://bugzil.la/1358879 FIXED, till@tillschneidereit.net Optimize handling of internally-created Promise objects more
19:04tracybmiroglio: ping
19:44billmfelipe: ping
19:44felipebillm: pong
19:44billmfelipe: hi, sorry I forgot to ping you back yesterday
19:44felipebillm: hey, np. I'm uncertain about the review for bug 1363877
19:45firebothttps://bugzil.la/1363877 NEW, wmccloskey@mozilla.com Label some SystemGroup runnables
19:45felipebillm: what would it mean if that is labeled as SystemGroup and some code ends up touching the DOM or page JS?
19:45billmfelipe: it would cause us to assert in debug builds
19:46felipebillm: but no security problem?
19:47felipebillm: I think I can inspect the current code to see that nothing touches it, but it's not guaranteed that no one will add something in the future.. some of those listeners are pretty broad functions
19:47billmfelipe: I don't think so
19:47billmfelipe: oh, also, this only matters for the content process
19:47felipeI don't recall if this filter is running in chrome or content
19:48billmfelipe: I think it's used in both
19:48billmfelipe: but I think the content process one just sends some messages
19:48felipeyeah, I think so
19:48felipeand what is the downside of not labeling it as SystemGroup?
19:49billmfelipe: it will make the Quantum DOM scheduler less effective
19:50felipeok
19:50billmfelipe: you know, now that I look, I don't think we use either of these notifications: onStatusChange or onprogresschange
19:50billmoh wait, we do
19:50felipeyeah, on browser.js at least
19:50billmhttp://searchfox.org/mozilla-central/source/toolkit/content/browser-child.js#189-197
19:51billmand here http://searchfox.org/mozilla-central/source/toolkit/content/browser-child.js#139-149
19:51felipeyeah. I guess it's guaranteed that these won't be hitting content due to the process boundary
19:51billmfelipe: also keep in mind that this stuff will not be used until FF57
19:51felipethe big functions are in browser.js
19:51billmfelipe: yeah. I think it's a pretty safe change. all we do is send some messages.
19:52felipein theory it could be a problem for non-e10s
19:52felipebut if that is only used after 57
19:52billmfelipe: no, this change only applies to the content process
19:52felipeah
19:52billmwe don't use these annotations at all in the parent
19:52felipeand it wouldn't apply to "content" in non-e10s mode?
19:53felipe(which is probably not a concern after 57 anyway...)
19:53billmno, there's an XRE_IsContentProcess() check
19:53billmwhich is always false in non-e10s
19:53felipealright, cool
19:53felipeok then, i'm more comfortable with this change now
19:54billmthe check is here if you're interested: http://searchfox.org/mozilla-central/source/xpcom/threads/SchedulerGroup.cpp#335
19:54billmok, sounds good
19:55felipebillm: would it be worth to add a comment in those functions in browser-child.js that you pointed, mentioning to not touch content from there?
19:55billmfelipe: sure, we could do that
19:56felipebillm: wait a sec, see the _setupObjects function there
19:56felipeand _setupJson
19:56felipeit has e.g. content.document.contentType
19:57billmfelipe: reads are okay
19:57billmfelipe: the danger is if we change anything, dispatch events, run content JS
19:58felipewhat about the content passed up as "contentWindow" in _setupObjects?
19:58billmfelipe: that's only used by add-ons, which we don't have to worry about when this code is used
19:58felipealright
20:01billmthanks
20:02felipenp
21:01tracybmiroglio: ping
21:11mstangeis there a known case of main thread IO in the content process?
21:11mstangeI'd like to check whether my main thread IO markers are showing up correctly
21:48bmirogliotracy: pong
17 May 2017
No messages
   
Last message: 6 days and 5 hours ago