880458 - Find a way to display the SDK Panel associated to an overflowed SDK Widget

Status: RESOLVED FIXED

(Firefox :: Toolbars and Customization, defect)

Description

[Matteo Ferretti [:zer0] [:matteo]]

SDK Widget can have (anchored) panel attached to them. We need to figured out how to deal with overflowed SDK Widget when they're clicked – they currently have their own panel, we can't use a `createWidget` with type `view`.

We should have an API that returns the XUL node where to display the anchored panel, e.g. the original Widget XUL Node if is not overflowed, and the chevron if it's overflowed; closing the previous chevron panel.

Comment 1

[:Gijs (he/him)]

I can have a look at this either tonight or tomorrow. Looks like there's already a property for panels to have an anchor, so we'd just need to deal with overflowable toolbars. I'll probably want to refactor some bits of the OverflowableToolbar support so it doesn't depend on hardcoded IDs in CustomizableUI.jsm... Mike, does that sound right to you?

Comment 2

[Mike Conley (:mconley) (:⚙️)]

So the menu panel has an anchor ID set on it, but I think that's separate (in fact, I'm not sure that's even useful anymore, since I'm not sure we ever want any other panel anchored to the menu panel button...I think that's an old idea that may not have taken off).

For the overflowable items, I think you just need to set the customizableui-anchorid attribute on them when they overflow - and set that to the chevron ID.

That way, the SDK *should* be able to choose the right anchor point simply by doing:

CustomizableUI.getWidget("someWidgetId").forWindow(window).anchor

Comment 3

[:Gijs (he/him)]

Attachment: Patch

So if I'm reading you right, this is all that's needed? setLocationAttributes should take care of anything/everything wrt moving the node to/from different locations.

Looking at this code has made me realize... I'm pretty sure our API calls for moving widgets all break down if the overflowable toolbar is, uh, overflowing. :'(

We can't do that in customization mode (because everything gets moved out of the overflowpanel), but it'll affect consumers like the SDK.

I'll file a separate bug for that.

Comment 4

[:Gijs (he/him)]

(In reply to :Gijs Kruitbosch from comment #3)
> Looking at this code has made me realize... I'm pretty sure our API calls
> for moving widgets all break down if the overflowable toolbar is, uh,
> overflowing. :'(
> 
> We can't do that in customization mode (because everything gets moved out of
> the overflowpanel), but it'll affect consumers like the SDK.
> 
> I'll file a separate bug for that.

Hrm. Seems it doesn't actually break, because it just inserts wherever it can. Not ideal, but maybe what we want not to upset too many assumptions?

Comment 5

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 773518 [details] [diff] [review]
Patch

Review of attachment 773518 [details] [diff] [review]:
-----------------------------------------------------------------

Yes, I think this is right.

Comment 6

[:Gijs (he/him)]

https://hg.mozilla.org/projects/ux/rev/4136556fa252

Comment 7

[Matteo Ferretti [:zer0] [:matteo]]

I notice an issue using the feature introduced in this bug: when I installed for the first time an add-on with a widget, the widget is displayed in the navbar, but it has the attribute "customizableui-anchorid" set to "nav-bar-overflow-button" even if is not "overflowed", and there is no overflow menu / chevron displayed.

When I close the browser, and I reopen it, everything works as expected – the attribute is present only if the widget is in the overflow panel or menu panel, with the right value –; so it seems happens only when the widget is added the first time.
Notice that customize the widget and move in the menu panel works as expected, but put the widget back to the navbar still shows the issue; until I restart the browser.

I think it's a bug; I'm expecting a consistent behavior between the first time the widget is added and after the browser is restarted.

Comment 8

[:Gijs (he/him)]

(In reply to Matteo Ferretti [:matteo] [:zer0] from comment #7)
> I notice an issue using the feature introduced in this bug: when I installed
> for the first time an add-on with a widget, the widget is displayed in the
> navbar, but it has the attribute "customizableui-anchorid" set to
> "nav-bar-overflow-button" even if is not "overflowed", and there is no
> overflow menu / chevron displayed.
> 
> When I close the browser, and I reopen it, everything works as expected –
> the attribute is present only if the widget is in the overflow panel or menu
> panel, with the right value –; so it seems happens only when the widget is
> added the first time.
> Notice that customize the widget and move in the menu panel works as
> expected, but put the widget back to the navbar still shows the issue; until
> I restart the browser.
> 
> I think it's a bug; I'm expecting a consistent behavior between the first
> time the widget is added and after the browser is restarted.

Please file a new bug and list the widget specification you used (in particular, defaultArea and so on), and how you add it to the navbar.

Comment 9

[Matteo Ferretti [:zer0] [:matteo]]

(In reply to :Gijs Kruitbosch from comment #8)

> Please file a new bug and list the widget specification you used (in
> particular, defaultArea and so on), and how you add it to the navbar.

This bug was about SDK Widget, so I mentioned "widget" in this meaning, sorry if it wasn't clear enough: so there is no "defaultArea" – I'm not using CustomizableUI API directly.

Anyway, I filed bug 906634, where I put more details about that: it seems that also this is applying to any buttons, when I start the UX build with a fresh profile.

Comment 10

[:Gijs (he/him)]

https://hg.mozilla.org/mozilla-central/rev/4136556fa252