User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b6pre) Gecko/20100909 Firefox/4.0b6pre Build Identifier: It would be nice to have some option for a "noautohide" attribute on the panels. As a use case, I have an XUL extension that replaces a site/forum's default text editor with a more advanced one that's stored in a panel, which is anchored to a button on the statusbar. The panel is set to noautohide, so the only way to close it is by toggling the statusbar button (or hitting the esc keyboard button while the panel has focus). This lets the users access the test editor no matter how far up the page from the default editor's position they have scrolled. If I were to completely convert my extension to the Jetpack SDK, without a noautohide attribute, every time the user interacts with the page itself, the advanced editor would disappear, and the user would have to toggle the editor's visibility themselves. I mean, noautohide=false should clearly be the default, but it would be nice to have a more persistent option available. Reproducible: Always
I'm assuming that panels are being auto hidden by a setTimeout, if that is so, then the delay should be customizable, along with being cancelable, so perhaps a showFor or closeDelay attribute that takes a int of ms to choose a custom hide delay or Number.POSITIVE_INFINITY to cancel the hide delay?
In XUL elements, "noautohide=false" just makes it so that if the panel element loses focus, it hides the panel. It's not an "auto-hide after XX ms" thing.
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".
Huh. Hacking onto panel.js in the addon-kit so that the show method adds the noautohide attribute to the xulPanel element makes it so the panel never goes away once shown. Duly noted.
this is somewhat related to Bug 637291
Despite what I said over in bug 637291, after rereading this bug's comments, I do see the use case for this functionality (separately from the "label" property in that other bug). However, "persist" seems like a better name than "noautohide".
Actually, for consistency with the other boolean properties in the high-level APIs, the name of this one should start with "is", i.e. "isPersistent".
(automatic reprioritization of 1.0 bugs)
Re-prioritizing all 1.1-targeted feature requests to 1.2.
(Pushing all open bugs to the --- milestone for the new triage system)
So, using `noautohide` attribute the panel will only be close when the `hidePopup` method is called explicitly (see https://developer.mozilla.org/en/XUL/panel#a-panel.noautohide); that's why the panel never goes away once shown. To implement this feature, we need to handle manually all the cases where we want to hide the panel. For instance, if the widget is clicked again, if ESC is pressed, and so on. There is still one scenario where I didn't find a good approach yet: when the `toolbar` is collapsed. Using `beforecustomization` event, I can hide the panels, but if I collapse / close the "addon bar" the panels are obviously still there. I didn't find any event fired in this occasion. One thing I could do, is using the DOM Mutation event on the container of the widget, and observes when the "collapsed" is changing. Of course, I have also to add / remove that listener during the customization of toolbars (because widget could change container, and the panels need to be hidden when the proper widget's container is collapsed). It sounds to me a bit hacky and especially costly – DOM Mutation events are not cheap, that's because Mutation observer are introduced, however they're not in release yet so I'm not sure if we want use them. I'm open to suggestions if anyone has a better approach. There are also another couple of UI problem: 1. What's happen when I have two widgets with two persistent panel? They will be easily overlapped, especially if the widgets' widths are lesser than the panels' widths. Is that what we want? Or only one persistent panel should be keep opened? 2. What's happen for multiple windows? At the moment we didn't care, because when we change focus the panel is hidden so only one panel can be displayed at the same time. But the panel's instance is always the same, it means if I open a new window when I have a persistent panel displayed in another window, I share the same instance – so can't be displayed in both windows at the same time. Therefore we probably needs a sort of `PanelView` like we had for the widget; or we can say that when you leave a window all persistent panels are closed by default. In addition, for persistent panel, we need to take in account the resize of the windows, because the position of the panel could change depending by the window's size. It seems that the attribute "flip" for panels doesn't really work as expected, especially for the arrow. What are your thoughts?
Just a note about the "toolbar collapse" issue. As alternative, we could modify the firefox code, and dispatch a custom event every time a toolbar changes its visibility attribute: http://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser.js#4603 It sounds to me a cleaner solution, but cannot be done just in jetpack.
So currently there's no way to work around this except hacking panel.js?
Wennan, copying over `panel.js` and modifying it is fairly easy. That might not be the only solution, but it is one that works.
(In reply to Gregg Lind (User Research - Test Pilot) from comment #16) > Wennan, copying over `panel.js` and modifying it is fairly easy. That might > not be the only solution, but it is one that works. Got it. Thank you!
Notice that bug 787395 once resolved, could give the capability to do similar things of a "persistent" panel, without the drawbacks.
Matteo, sounds like that bug doesn't allow for arbitrary placement and anchoring of the panel. My fantasy (for UI experiments mostly), is "Arbitrary HTML in a box anywhere, that can interact with chrome element, and live in that scope". That bug is a good feature idea though!
(In reply to Gregg Lind (User Research - Test Pilot) from comment #19) > Matteo, > > sounds like that bug doesn't allow for arbitrary placement and anchoring of > the panel. My fantasy (for UI experiments mostly), is "Arbitrary HTML in a > box anywhere, that can interact with chrome element, and live in that > scope". Adding Stephen, for completeness' sake as the heart of the discussion around this widget idea is impacted by UX guidance. Gregg: That sounds like an excellent idea for a module, but I don't think it is in scope for a widget we ship with Firefox. If you really think we should have such a widget available to any add-on installed in Firefox, you may need to convince UX of its' worthiness, but I don't think that should stop you from exploring the idea as a 3rd party module.
+1 for a dialog like panel which is not limited to the sidebar and allows for normal restrained content script communication (unlike windows/utils' open()). Apparently others in addition to myself are looking for something similar as well: http://stackoverflow.com/questions/13494722/firefox-add-on-sdk-make-panel-to-stay-visible .
(In reply to Brett Zamir from comment #21) > +1 for a dialog like panel which is not limited to the sidebar and allows > for normal restrained content script communication (unlike windows/utils' > open()). Unfortunately there is nothing like that in the close future. We have now sidebar and toolbar content with HTML inside, and in the near future we'll have devtools panel too. As Jeff said the idea of Gregg is nice as 3rd party module, and maybe that could be convinced UX of its' worthiness; I don't think there is any UI component like that in regular Firefox atm.