643131 - Add a .hide() method to Widgets

Status: RESOLVED WONTFIX

(Add-on SDK Graveyard :: General, enhancement, P2)

Description

[Hernán Rodriguez Colmeiro (:peregrino)]

It would be very useful to have the option of hiding a widget, and not having to destroy it when you actually want it hidden.

Since widgets now have an ID and can remember their position this might be easier to do.

Comment 1

[Dietrich Ayala (:dietrich)]

The create/destroy approach doesn't really lend itself to temporary widgets. Also, having hide/show would be consistent with Panel.

However, what are some use-cases for widgets that needed to be hidden and re-shown, as opposed to destroyed and re-created?

Comment 2

[Hernán Rodriguez Colmeiro (:peregrino)]

(In reply to comment #1)
> However, what are some use-cases for widgets that needed to be hidden and
> re-shown, as opposed to destroyed and re-created?

The primary use case that I encountered for this is an addon that has different UI depending on the URL shown. Then each time you change tabs, or browse to a new URL, the UI changes. 
Right now the only solution is to code a widget manager that keeps track of that, but has to destroy/create widgets all the time, slowing down rendering and creating avoidable overhead.

Comment 3

[Dietrich Ayala (:dietrich)]

(In reply to comment #2)
> The primary use case that I encountered for this is an addon that has different
> UI depending on the URL shown. Then each time you change tabs, or browse to a
> new URL, the UI changes. 

Why can't you change the widget's content on those events?

Comment 4

[Hernán Rodriguez Colmeiro (:peregrino)]

(In reply to comment #3)
> (In reply to comment #2)
> > The primary use case that I encountered for this is an addon that has different
> > UI depending on the URL shown. Then each time you change tabs, or browse to a
> > new URL, the UI changes. 
> 
> Why can't you change the widget's content on those events?

Well, you can. 
My primary concern was when you wanted some widget to actually dissapear, had it content completely gone. I couldn't set it's content to `''` because widgets need to have some content, and I also couldn't hide it, so the only option was to destroy it. Now suppose that is the 2nd of 3 widgets that ought to be in that precise order, how do you insert it back when needed in the correct position? 
The solution I found was to maintain a widget tracker that remembered the position of the widgets, but it isn't something I'm proud of :/
All that could be easily done with just `wgTest.hide();` when you want it out of the way, and `wgTest.show();` when you need it back.

Comment 5

[Nicolas Côté-Nolin]

I agree with Hernán it could be useful. 

My use case : we inject some content on every page (pagemod) but have a close button for when the user doesn't want to see it. When that happens we would like to show the widget and when clicked on it, show the content that we injected and hide the widget.

Comment 6

[Myk Melez [:myk] [@mykmelez]]

(automatic reprioritization of 1.0 bugs)

Comment 7

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Marking anything that potentially looks like a feature request as "enhancement", sorry for the bugspam. :)

Comment 8

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Re-prioritizing all 1.1-targeted feature requests to 1.2.

Comment 9

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

(Pushing all open bugs to the --- milestone for the new triage system)

Comment 10

[Erik Vold [:erikvold] (please needinfo? me)]

Taking myself off things that I won't be able to get to for awhile.

Comment 11

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

After the meeting about the new UX stuff, I believe this bug is a WONTFIX. Mainly because hiding the widget in a toolbar it seems against UX guidelines; and because we're going to focus on new components.

For the use case described in comment #2, we'll have the location bar's component (see https://github.com/mozilla/addon-sdk/wiki/JEP-Add-on-UI-Integration); the "widgets" in toolbar won't be able to disappear but only to change its status (icon, badge, enable/disable, etc), to avoid the toolbar to "jumping" (not sure as describe in English).

Comment 12

[Jeff Griffiths (:canuckistani) (:⚡︎)]

(In reply to Matteo Ferretti [:matteo] [:zer0] from comment #11)
> After the meeting about the new UX stuff, I believe this bug is a WONTFIX.
> Mainly because hiding the widget in a toolbar it seems against UX
> guidelines; and because we're going to focus on new components.

Agreed.

Comment 13

[Hernán Rodriguez Colmeiro (:peregrino)]

I have no issues with wontfixing this.

Comment 14

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

Everyone seems to agree; I set this bug as WONTFIX then.