Closed Bug 900122 Opened 12 years ago Closed 12 years ago

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

Categories

(Firefox :: Toolbars and Customization, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: jaws, Unassigned)

References

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.
Blocks: 890319
Whiteboard: [Australis:P?][Australis:M?]
Whiteboard: [Australis:P?][Australis:M?] → [Australis:P5][Australis:M?]
Jared, are you OK wontfixing this?
Flags: needinfo?(jaws)
Yep, we've moved on from this idea. Thanks for the ping!
Status: NEW → RESOLVED
Closed: 12 years ago
Flags: needinfo?(jaws)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.