Open Bug 930172 Opened 11 years ago Updated 2 years ago

Dynamically resize customizable icons as they are dragged over their destination

Categories

(Firefox :: Toolbars and Customization, defect)

defect

Tracking

()

People

(Reporter: liuche, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [Australis:P-])

STR:
1. Drag icon from "More Tools to Add to the Menu and Toolbar" pane to the urlbar.

Expected:
Preview of what that would look like, with an appropriately-sized transparent icon hovering over the urlbar.

Actual:
Giant transparent icon hovering over the location. Analogously, dragging an icon _from_ the urlbar displays a tiny urlbar-icon-sized preview.

When adding an icon from the customization menu, it would be nice if the icons could smoothly resize to fit the space to give an idea of what end result would actually look like.

...smooth dynamic resizing seems like it would be a *lot* of work.
I'm not sure we can even do this at all for toolbar items. For toolbar buttons, maybe, but for toolbar items... How would we get e.g. the zoom controls to do this (as the middle button (dis)appears)?

(Picking priority somewhat randomly, feel free to disagree)
Whiteboard: [Australis:P3]
(In reply to :Gijs Kruitbosch from comment #1)
> I'm not sure we can even do this at all for toolbar items. For toolbar
> buttons, maybe, but for toolbar items... How would we get e.g. the zoom
> controls to do this (as the middle button (dis)appears)?

AFAIK the middle button doesn't disappears anymore.
(In reply to Guillaume C. [:ge3k0s] from comment #2)
> (In reply to :Gijs Kruitbosch from comment #1)
> > I'm not sure we can even do this at all for toolbar items. For toolbar
> > buttons, maybe, but for toolbar items... How would we get e.g. the zoom
> > controls to do this (as the middle button (dis)appears)?
> 
> AFAIK the middle button doesn't disappears anymore.

Huh, fascinating. Filed bug 932719 because it doesn't look great on OS X. :|
Transitioning between the various states/views of the buttons/items may be "hard" but showing them in those states might be doable. The basic idea here is to use a <xul:panel> that is positioned absolutely within the browser window based on the coordinates of the most recent mousemove event. This panel can have a background image that uses background:-moz-element(XXX) and we can reference the similar code that we use to figure out the size of the element when it is going to be placed in each area.

This floating panel approach will work hand-in-hand with what I am trying to do in bug 879981.
(In reply to Jared Wein [:jaws] from comment #4)
> This floating panel approach will work hand-in-hand with what I am trying to
> do in bug 879981.

In that the panel won't get positioned outside of an area if the element being dragged is not removable.
Assignee: nobody → jaws
Status: NEW → ASSIGNED
OS: Mac OS X → All
Hardware: x86 → All
Whiteboard: [Australis:P3] → [Australis:P3][Australis:M?]
Unless there's an easy and obvious fix for this, I think we should pass on this for Australis v.1.
Whiteboard: [Australis:P3][Australis:M?] → [Australis:P-]
Assignee: jaws → nobody
Status: ASSIGNED → NEW
I believe that Bookmark Toolbar Items should be resized once they leave Bookmarks Toolbar.
(if someone is going to ever fix this bug)
Blocks: 1192911
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.