900408 - Australis: Investigate dynamically inserting customization mode XUL

Status: RESOLVED WONTFIX

(Firefox :: Toolbars and Customization, defect)

Description

[:Gijs (he/him)]

I was poking around browser.xul for an unrelated reason and found http://hg.mozilla.org/mozilla-central/annotate/ccd8ad8a4604/browser/base/content/browser.xul#l1117 (couldn't figure out from the bug how big the tspaint win had been / what was tried, etc.)

Did we already investigate just not appending the customize mode XUL to that deck until the user clicks customize?

Comment 1

[:Gijs (he/him)]

(Dolske, CC-ed you because the cset in question says this was feedback from you, so maybe you remember?)

Comment 2

[Jared Wein [:jaws] (please needinfo? me)]

I don't think that was looked at before, but definitely seems like something easy that we could try :)

Comment 3

[Justin Dolske [:Dolske]]

I don't remember why this was, would have to dig into ancient bugs.

I'd assume it was because the iframe is going to spin up a new document and load it, and iframes by defn'n block the top-level load event. If you're talking about the #include of customizeMode.inc.xul, I wouldn't expect that to have any significant effect since it's mostly just some boxes.

But I suppose you're pulling in a stylesheet, and maybe some binding stuff? Might be worth a quick'n'dirty removal of the #include to see if it matters.

Comment 4

[:Gijs (he/him)]

Computer says no:

http://perf.snarkfest.net/compare-talos/index.html?oldRevs=25a2e1f00276&newRev=ee730290b24a&submit=true

:-(

Comment 5

[:Gijs (he/him)]

We're getting very close so I wanted to look at this again. This time, also removed the now-useless deck:

https://tbpl.mozilla.org/?tree=Try&rev=4d76b26b4d75

Baseline: https://tbpl.mozilla.org/?tree=Try&rev=cf7b7a5eb0d5

Pre-emptive compare-talos:

http://perf.snarkfest.net/compare-talos/index.html?oldRevs=cf7b7a5eb0d5&newRev=4d76b26b4d75&submit=true

(not reopening until I see some results)

Comment 6

[Jared Wein [:jaws] (please needinfo? me)]

Using Matt's compare-talos, http://compare-talos.mattn.ca/?oldRevs=cf7b7a5eb0d5&newRev=4d76b26b4d75&submit=true

This shows a small change (-.36ms or -.25%) on tpaint for WinXP so maybe it's worth taking anyways? It seems to be across the board decreases in time on tpaint/ts_paint-med/ts_paint-max with the exception of 10.8 and Win8, both of which show small upticks in time, which doesn't make much sense.

Comment 7

[Dão Gottwald [:dao]]

(In reply to Jared Wein [:jaws] from comment #6)
> It seems to be across the board decreases in time
> on tpaint/ts_paint-med/ts_paint-max with the exception of 10.8 and Win8,

And 10.7, that makes an increase for half of all platforms.

> both of which show small upticks in time, which doesn't make much sense.

It probably just means that there's basically no win and the noise makes it sometimes an increase, sometimes a decrease.

Comment 8

[:Gijs (he/him)]

WONTFIXing per bug 902857 comment 16.