Investigate moving customization markup from browser.xul to an external file

RESOLVED WONTFIX

Status

()

RESOLVED WONTFIX
5 years ago
5 years ago

People

(Reporter: jaws, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Australis:P5][Australis:M?])

We currently put all of the customization markup within browser.xul (via an #include), although if the user never visits Customization Mode then we have loaded markup unnecessarily.

We should investigate moving customization mode out to an external file, similar to how we do extensions.xul, and just load customize.xul (or some other name for it) when the user enters customization mode.
The downside to doing this is that add-ons will have to overlay this customize.xul file instead of just relying on their normal styling "just working", however this would not be a regression from the pre-Australis implementation that required add-on authors to overlay the customizeToolbar.xul file.
Running a locally altered tpaint with a patch that removed the <deck> and the #included XUL file, this actually showed slightly worse performance (~4ms) which doesn't make any sense to me. It's possible that removing it made no performance and the ~4ms are just noise, however I think this bug should still be pursued further.
Whiteboard: [Australis:P?][Australis:M?]
Whiteboard: [Australis:P?][Australis:M?] → [Australis:P5][Australis:M?]

Comment 3

5 years ago
Jared, are you OK wontfixing this?
Flags: needinfo?(jaws)
Yep, we've moved on from this idea. Thanks for the ping!
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Flags: needinfo?(jaws)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.