Closed
Bug 1446957
Opened 7 years ago
Closed 7 years ago
The <xul:browser> constructor forces the creation of an about:blank content viewer
Categories
(Toolkit :: UI Widgets, enhancement, P5)
Toolkit
UI Widgets
Tracking
()
RESOLVED
DUPLICATE
of bug 1493606
People
(Reporter: florian, Unassigned)
Details
(Whiteboard: [fxperf:p2])
Each time a new browser window is opened, we create a non remote browser, and its constructor creates an about:blank content viewer with this stack:
0 get_contentWindow() ["chrome://global/content/bindings/browser.xml":462]
1 get_securityUI() ["chrome://global/content/bindings/browser.xml":880]
2 browser_XBL_Constructor() ["chrome://global/content/bindings/browser.xml":975]
Soon after that, in most cases this browser is destroyed when it's replaced with a remote browser.
In addition to being useless, this about:blank load causes annoying page load notifications that the front-end code somehow has to workaround to avoid flicker.
Reporter | ||
Comment 1•7 years ago
|
||
The obvious 'fix' is to just remove this obscure code from browser.xml: https://searchfox.org/mozilla-central/rev/3abf6fa7e2a6d9a7bfb88796141b0f012e68c2db/toolkit/content/widgets/browser.xml#972-976
try {
// Ensures the securityUI is initialized.
var securityUI = this.securityUI; // eslint-disable-line no-unused-vars
} catch (e) {
}
But I'm not 100% sure that's correct. Eg. the code and comments at https://searchfox.org/mozilla-central/rev/3abf6fa7e2a6d9a7bfb88796141b0f012e68c2db/toolkit/components/browser/nsWebBrowser.cpp#1280-1293 make me wonder if not registering the securityUI object earlier enough could cause us to miss some secure/insecure notifications.
And also, removing this code just pushes the problem slightly further, with the new stack being:
0 get_contentWindow() ["chrome://global/content/bindings/browser.xml":462]
1 get_outerWindowID() ["chrome://global/content/bindings/browser.xml":431]
2 updateBrowserRemoteness() ["chrome://browser/content/tabbrowser.js":1593]
3 onDOMContentLoaded() ["chrome://browser/content/browser.js":1279]
4 anonymous() ["chrome://browser/content/browser.js":1201]
That's from https://searchfox.org/mozilla-central/rev/3abf6fa7e2a6d9a7bfb88796141b0f012e68c2db/browser/base/content/tabbrowser.js#1592 when destroying the non-remote browser:
// Unmap the old outerWindowID.
this._outerWindowIDBrowserMap.delete(aBrowser.outerWindowID);
Reporter | ||
Comment 2•7 years ago
|
||
I marked this fxperf:p1 when I thought I could trivially fix it, but this now seem like a bigger effort than I initially expected.
Whiteboard: [fxperf:p1] → [fxperf:p2]
Updated•7 years ago
|
Priority: -- → P5
Comment 3•7 years ago
|
||
I'm going to dupe this over to the metabug in which I'm attacking this problem. I've already removed the security UI component from the <browser> constructor, but the outerWindowID accessors are the next issue, which I'm hoping to address in bug 1496360, once I move the outerWindowID to docshell.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•