Closed Bug 586029 Opened 14 years ago Closed 13 years ago

widgets need a way to specify where in the UI they should appear

Categories

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

defect

Tracking

(Not tracked)

RESOLVED WONTFIX
Future

People

(Reporter: dietrich, Assigned: ochameau)

References

Details

(Whiteboard: [addon bar])

Attachments

(1 file, 2 obsolete files)

The idea for add-on UI in Firefox 4 is that widgets should appear in the add-on bar by default, but should be able to also show up on the navigation toolbar, the bookmarks toolbar and on the add-ons sub-menu of the Firefox menu (if that comes to be).

This means that the widget module in the Jetpack SDK needs to provide a way for authors to specify where their add-on should appear.

The following questions need to be answered:

* Should they be able to appear in >1 location?

* What is the list of supported locations?

The changes required in the widget module look something like:

* Add a property to the widget ctor that takes the location(s)
* Add support for menu-hosted widgets
* Add support for location-contextual scaling of widgets
* Add support for generation of scaled static images from dynamic content for widgets on menus (P2)
* Ensure multiple simultaneous widget instances per-window work correctly
* Document the locations, and differences in widget behavior based on context
Is the idea that addons would decide where their widgets appear, that users would get to customize the locations (just as they currently customize the locations of toolbars), or both?

Also, I have mixed feelings about overloading the widget API with menu item functionality, given the somewhat different interaction models of the two (wrt. location customization, support for dynamic content, anchoring of panels, support for sub-menus, etc.).

Nevertheless, I'm open to the idea, but let's also consider what it would look like if the API for adding a menu item to the addons submenu of the Firefox menu were a separate module rather than part of the widget module.
(In reply to comment #1)
> (just as they currently customize the locations of toolbars)

Erm, I meant to say: "just as they currently customize the locations of toolbar *items*."
Yeah, I didn't mean to suggest in my mailing list posting that tying Firefox menu support to widget is the right way to go, only that it's an example of how we might support it without a dedicated menu or even "Firefox menu" API.  Having thought about it more, I think it's a bad idea, since widget means flexible little iframes, which aren't possible or appropriate in menus.
Assignee: nobody → dietrich
The Add-on SDK is no longer a Mozilla Labs experiment and has become a big enough project to warrant its own Bugzilla product, so the "Add-on SDK" product has been created for it, and I am moving its bugs to that product.

To filter bugmail related to this change, filter on the word "looptid".
Component: Jetpack SDK → General
Product: Mozilla Labs → Add-on SDK
QA Contact: jetpack-sdk → general
Version: Trunk → unspecified
Attached patch work in progress (obsolete) — Splinter Review
This doesn't actually change anything important yet.

It adds an error and validation constraints for a "toolbar" option, and adds the option to the widget's constructor.

I'm not quite sure what to do to actually get the option to be obeyed. It looks like the "addon-bar" is being specified in BrowserWindow.prototype's "container" getter. If I understand it correctly, though, "container" is the globally available setting for all widgets, so changing it there would change it for every widget, which wouldn't be right.

BrowserWindow does have access to _items, but that's all of the widgets, and we can't tell which one is the current one.

Dietrich, Myk, any ideas?
Whiteboard: [addon bar]
Wes: I'm not very familiar with this code, and a quick look doesn't immediately give me ideas. :-(
Changes landed yesterday that help this along a little: customized widgets (eg: dragged to a different toolbar than add-on bar) are now properly added to the correct toolbar after restarts.

Comments on the patch:

* I think we should use some constants for the built-in toolbars instead of having the DOM ids used directly. I don't think this necessarily has to be in Widget. Maybe a Firefox or generic App module that exposes a toolbars property, which is a list of built-in toolbars?

* Look in BrowserWindow._addItemToWindow. From there you can access the options of the widget being added. The container getter would just be used in the default case. Otherwise, get the node of the specified toolbar in the widget options.
Taking a step back, are we sure we want addons to be able to choose where they add their widgets?  I understand giving users the ability to move widgets elsewhere, but the use cases for addon customization of widget placement are less clear.

Didn't we create the addon bar so that there would be one common and known location for addons to present their UI, so users would always know that an addon that presented a chrome interface would do so in the addon bar?
At the least they should be able to specify if they're available in pop-up windows from window.open(...), and Add-ons can already specify that they want to be in Context Menus, e.g.
Priority: -- → P2
Target Milestone: --- → Future
Here is a simple way to add this feature on top of my last widget improvements.

myk: I need some feedback before writing doc'n tests. 

I'd say that this is a commonly asked feature. I think the question is more: 
- Do we want to control this feature by providing an API for that ? 
- Or do we let third party API to propose that ?
- Do we want to offer a more satisfying UI for adding addon action in browser UI ?

Some jetpack already implement such button:
https://addons.mozilla.org/en-us/firefox/addon/read-later-fast/
They are doing it hardly by reimplementing mostly the widget API and try do handle unload nicely without being sure that they are doing it right.
Assignee: dietrich → poirot.alex
Attachment #512556 - Attachment is obsolete: true
Attachment #524504 - Flags: feedback?(myk)
(In reply to comment #10)
> myk: I need some feedback before writing doc'n tests. 

I can speak to API design and implementation, but I could use some help thinking through the implications for users, for which cc:ing Alex Faaborg.

Alex: the question here is whether to allow SDK-based addon developers to add widgets to the Navigation Toolbar in addition to the Add-on Bar.  Currently, the SDK's Widget API only permits adding widgets to the Add-on Bar, although users can move widgets to the Navigation Toolbar via toolbar customization.

As I recall, the purpose of the Add-on Bar is to consolidate addon buttons/icons/widgets in a known location in the browser chrome, so users who install an addon with UI will know where to look for it.  So I'm hesitant to allow addon developers to put their widgets elsewhere by default, since that makes it harder for users to find them.

On the other hand, presumably very few users customize their toolbars, and if a particular widget works better in the Navigation Toolbar, it is more likely to live there if the addon developer puts it there than if users do.

Any thoughts on what the right thing to do for users is in this case?
Developers will all view the navigation toolbar as higher value real estate, and opt to place their control there.  I think we should continue with a single insertion point, and then once we've collapsed the search field and location bar into a single entity, we'll probably have enough room to move them all up to the navigation toolbar at the same time.
One more consideration here, while we are currently adding things to the add-ons bar with desktop Firefox, in a different context (mobile, tablet, etc.)  The interface used to surface extensions could be entirely different, so I think it is conceptually a lot cleaner for developers to have a single insertion point. And this gives us the freedom later to redefine the interface and have everything smoothly carry over.
Comment on attachment 524504 [details] [diff] [review]
Add widget.position attribute that can be "addon-bar" or "url-bar"

Ok, per Alex, let's stick with a single insertion point.
Attachment #524504 - Flags: feedback?(myk) → feedback-
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
(In reply to comment #12)
> Developers will all view the navigation toolbar as higher value real estate,
> and opt to place their control there.  I think we should continue with a single
> insertion point, and then once we've collapsed the search field and location
> bar into a single entity, we'll probably have enough room to move them all up
> to the navigation toolbar at the same time.

Coming from the mobile side of Firefox I tend to think about spaces like that:
 * if the screen is wide, use the horizontal space
 * if the screen is tall, use the vertical space

So In my opinion if you use only a few addons, this is likely to be much better to have them in the navigation toolbar than in the addons bar since the later took a complete line of vertical space (which is probably too much a lot if you have a small screen like an eeepc)


(In reply to comment #13)
> One more consideration here, while we are currently adding things to the
> add-ons bar with desktop Firefox, in a different context (mobile, tablet, etc.)
>  The interface used to surface extensions could be entirely different, so I
> think it is conceptually a lot cleaner for developers to have a single
> insertion point. And this gives us the freedom later to redefine the interface
> and have everything smoothly carry over.

About Firefox Mobile this is legitimate to not add buttons to the urlbar since it is so small, but the "navigation" buttons lived on the right sidebar which is the logical insertion point for things living into the navigation toolbar in desktop Firefox. We have no such things like an addon-bar, some has proposed it (http://joliclic.free.fr/blog/index.php?post/2011/01/12/A-proposal-for-Fennec%3A-an-additional-toolbar-for-extensions) but nothing has been decided yet.

So, I would like you to consider this bug again.
(In reply to comment #15)
> So In my opinion if you use only a few addons, this is likely to be much better
> to have them in the navigation toolbar than in the addons bar since the later
> took a complete line of vertical space (which is probably too much a lot if you
> have a small screen like an eeepc)

I agree, it makes sense for addon widgets to be in the navigation toolbar.  However, I think the right plan for getting there is the one Alex proposed, which is to move all addon widgets to the navigation toolbar in conjunction with changes to that toolbar to accommodate the widgets.


> About Firefox Mobile this is legitimate to not add buttons to the urlbar since
> it is so small, but the "navigation" buttons lived on the right sidebar which
> is the logical insertion point for things living into the navigation toolbar in
> desktop Firefox. We have no such things like an addon-bar, some has proposed it
> (http://joliclic.free.fr/blog/index.php?post/2011/01/12/A-proposal-for-Fennec%3A-an-additional-toolbar-for-extensions)
> but nothing has been decided yet.

Ah, that's an interesting proposal!  Have the Firefox Mobile developers seen it?  It would be good to get their feedback and work with them to figure out the right place to put addon widgets in the mobile interface.


> So, I would like you to consider this bug again.

I agree that we need a place for widgets in the mobile UI, but this bug isn't about that, it's about making the location of widgets on Firefox Desktop be an option for the addon developer, and that doesn't provide the best developer or user experience, neither on desktop nor on mobile.

Let's instead work to move all addon widgets to the navigation toolbar by default in a future Firefox Desktop version and figure out a place for them to live in a future Firefox Mobile version.
Attached patch Updated patch.Splinter Review
Anthony, working in Paris office asked me about an alternative way of displaying a widget in Firefox UI. Addon-bar isn't an option for his addon.
Attachment #524504 - Attachment is obsolete: true
Thank you for building that, Alexandre, that is mighty handy.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: