Closed Bug 997104 Opened 10 years ago Closed 6 years ago

CustomizableUI assumes that the toolbar.xml binding is always applied

Categories

(Firefox :: Toolbars and Customization, defect)

29 Branch
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: quicksaver, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [Australis:P-])

All throughout the code, CUI assumes that if a toolbar node is registered, then its binding must be applied as well. But if the toolbar happened to be hidden in the meantime, or placed in a hidden parent, then the binding would no longer be applied.

This causes several exceptions in pretty much every widget placement call that happens to involve that toolbar (createWidget, destroyWidget, ensureWidgetIsPlacedInWindow, addWidgetToArea...), often in this case I would have my widgets nuked because of this. unregisterArea was also very problematic in the same aspect. In all these cases, code execution would also be halted if not in a try/catch.

Obviously this is avoidable on the add-on side (which wasn't as easy to achieve as you might expect), but I think there should be some safeguards against CUI proceeding with whatever operation if the toolbar doesn't have the binding applied.
Why would the toolbar be hidden? Firefox normally uses "collapsed" to hide toolbars.
Flags: needinfo?(quicksaver)
For example, in OmniSidebar I add a toolbar to the sidebarheader, and when the sidebar closes it is hidden, so the toolbar.xml binding no longer applies.
Flags: needinfo?(quicksaver)
I was referring more to toolbars in non-conventional places (basically anything that's not in the top chrome).
Whiteboard: [Australis:P-]
We might make changes as part of de-xbl, but not here.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.