879223 - A reset() when not customizing throws off the overflowable navbar (in some cases?)

Status: RESOLVED WONTFIX

(Firefox :: Toolbars and Customization, defect)

Description

[:Gijs (he/him)]

I end up with a chevron that wasn't there before, which shows no content (probably because the navbar code is sticking hidden items, like the social stuff, in there?). I'm not sure why there's even an overflow event posted; the items should fit fine after a reset(). :-\


STR:
1. Open UX.
(if necessary, open customization mode, click "restore defaults")
2. Open browser console.
3. Execute: window.CustomizableUI.reset()

AR:
Chevron appears, no items are shown in its panel (on OS X Lion, the chevron also has a weird icon?)

ER:
No chevron.

Comment 1

[:Gijs (he/him)]

Alexander Limi was also reporting oddness: http://cl.ly/image/160M1O1k230u

Not sure what's going on here, but it'd be good if we could fix some of this for M7, even better if it wouldn't be quirky for the user reviews...

Comment 2

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

<jaws> Gijs: is there an actual use case for fixing bug 879223? when would a user open the scratchpad and run reset?
<Gijs> jaws: oh, I just gave usable STR
<jaws> or maybe that's just the easiest way to repro this bug? i know how to fix it, but i'm not sure it is worth the churn
<Gijs> jaws: actual use cases would be add-ons doing stuff and not checking if we're in customization mode.
<jaws> we expect addons to call reset?
<Gijs> I suppose reset isn't that useful, that's true.
<Gijs> Sorry, I filed a similar bug about the add/move/remove APIs
<jaws> ok no problem. i'll close it out then
<Gijs> I mean, in fact, we have two reset calls.
<Gijs> one on CustomizableUI, one on CustomizeMode
<Gijs> ideally, we should have only one exposed, and one that Just Worked.
<Gijs> But yeah.
<Gijs> perfect worlds don't exist.
<Gijs> yada yada
<jaws> yeah weird, but ok