There are quite a few extension use-cases (MailPing being the live one) which call for the visible state of a panel to persist when the user mouses over it, and the event option to hide itself when the user mouses out (of course this ability could be mixed into any other event combo the developer uses to show/hide the panel) I have implemented this in MailPing by delaying the panel's hide() call for a long enough period that allows for users to enter the window of the panel which then triggers a clearTimeout on the timer that contains said hide() call. Mouseout of the panel then messages the add-on to fire the hide() method. The hide() delay should be an option in the panel constructor and they should be able to specify something like "mouseoverShow: true" to signify they would like a mouseover of the panel to clear any hide() that is in queue. The implementation would be much more simple than the route used in MailPing because with direct access to the panel, and the ability to add an event directly to it, you wouldn't have to do the message passing craziness to set and clear the hide() timeouts.
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
Assigning to Dave to dig in on the UX implications.
Assignee: nobody → dcm
Priority: -- → P3
Target Milestone: --- → Future
(Pushing all open bugs to the --- milestone for the new triage system)
Target Milestone: Future → ---
Myk, Dave, what's the status on this bug?
Wes: hmm, looks like we've dropped the ball on this one. Re-reading the description, it's not entirely clear to me what is being requested here, although it reminds me of bug 595040, and I wonder if the fix for that one might adequately address the use case here.
The original request was to allow for the panel to be accessed with a mouse over of the widget, then to stay in view if the user chose to then mouse onto it. Thinking of the common UI interactions on the web might help. Many sites have hover-over panels that you can view stuff in, push a button in, that don't require a click to open and close as a window would. A tooltips, dropdown menus with rich content, etc.
(In reply to Myk Melez [:myk] from comment #5) > although it reminds me of bug 595040, and I wonder if the > fix for that one might adequately address the use case here. Not sure how setting "isPersistent" to a panel so it always stays visible unless explicitly hidden with hide() would add the ability to show/hide on hover/mouseover of a panel and its associated widget.
Ah, right, sorry folks, I misunderstood.
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.