Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Logging e10s warnings in debug builds?
20 views
Skip to first unread message
Chris Peterson
Dec 10, 2013, 2:06:00 AM12/10/13
to mozilla-dev-te...@lists.mozilla.org
Most Firefox developers are not testing e10s yet, but maybe we can help
them identify some e10s problems now.
Are there any extra warnings or assertions we could log in debug builds
to identify e10s problems even when browser.tabs.remote is false? Is it
possible, for example, to determine at runtime whether docShell is being
used in ways that would break if e10s had been enabled? I realize these
checks might not be feasible; I'm just trying to think of ways to make
the road to e10s smoother for everyone. <:)
Extra warnings would also be useful when debugging why some Firefox
feature or add-on breaks when e10s is enabled.
chris
them identify some e10s problems now.
Are there any extra warnings or assertions we could log in debug builds
to identify e10s problems even when browser.tabs.remote is false? Is it
possible, for example, to determine at runtime whether docShell is being
used in ways that would break if e10s had been enabled? I realize these
checks might not be feasible; I'm just trying to think of ways to make
the road to e10s smoother for everyone. <:)
Extra warnings would also be useful when debugging why some Firefox
feature or add-on breaks when e10s is enabled.
chris
Felipe Gomes
Dec 10, 2013, 10:57:40 AM12/10/13
to Chris Peterson, mozilla-dev-te...@lists.mozilla.org
> Is it
> possible, for example, to determine at runtime whether docShell is being
> used in ways that would break if e10s had been enabled?
Drew worked in the past in a bug to do this: https://bugzilla.mozilla.org/show_bug.cgi?id=666713
> possible, for example, to determine at runtime whether docShell is being
> used in ways that would break if e10s had been enabled?
IIRC it was very useful to guide us through the first major bugs when we were getting the front-end
to stand up.
Enabling something like this by default at this point would probably generate too much noise, but hopefully
when there's less noise it can be useful to help people avoid introducing newer points of failure.
I can't tell how bitrotten the patch is because it touches mostly JS/wrapper code that I don't have
experience with, but someone from JS can probably tell.
We can do some other spot logging like when the front-end tries to access `contentWindow` or `browser.docShell`
(as they go through getters that we can control easily), though each of those is limited in coverage (but maybe
still useful?)
Another type of logging that came to mind yesterday is that we could log when the content process tries to access
anything in the file system. That would help more the work of "ok, what's next that we need to fix".
Felipe
dev-tech-electrolysis mailing list
dev-tech-e...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-electrolysis
0 new messages