Closed Bug 374471 Opened 13 years ago Closed 4 years ago

popup.enableRollup

Categories

(Toolkit :: XUL Widgets, defect)

x86
All
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla47
Tracking Status
firefox47 --- fixed

People

(Reporter: pitrasw, Assigned: neil)

Details

Attachments

(1 file, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2

popup.enableRollup(bool) invoked while popup is displaying should work immediatly. So when popup is displaying and popup.enableRollup(false) was invoked right after showing the popup, the lower code should work and should cause to hide the popup after user put pointer over the popup and after that move cursor out of the popup and clicks somewhere beside the popup:

<popup
onmouseout="this.enableRollup(true)" >

</popup>



Reproducible: Always

Steps to Reproduce:
1. open popup and invoke popup.enableRollup(false)
2. now when popup is displaying invoke popup.enableRollup(true)
3. click somewhere beside the popup, it should hide
Actual Results:  
popup doesn't hide

Expected Results:  
popup should hide as enableRollup(true) was invoked
Component: Menus → XUL Widgets
Product: Firefox → Toolkit
QA Contact: menus → xul.widgets
enableRollup no longer does anything. The noautohide attribute should be used instead. 
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
Attached patch Possible patch (obsolete) — Splinter Review
I was interested in creating a "push-pin" style effect for a panel, whereby the autohide status was determined interactively. While I could emuulate this using a normal and a noautohide panel, it would be much neater if I could reimplement enableRollup as it does exactly what I need.
Attachment #8690918 - Flags: feedback?(enndeakin)
Comment on attachment 8690918 [details] [diff] [review]
Possible patch

The concept looks ok; I didn't look at the code in detail. Did you intentionally use Detach only in the first block?

A mild concern is that popup is always placed at the top of opposite list, rather than where it was, but that's already a bit of a mess.

One concern is that on GTK, the noautohide flag also controls whether the window manager handles the window or ignores it, so pressing a 'pushpin' button won't make it act like the other type in other often subtle ways. We've had some problems I think where someone wanted to change the noautohide attribute after the popup was created and it had odd problems.
Attachment #8690918 - Flags: feedback?(enndeakin) → feedback+
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: WONTFIX → ---
Assignee: nobody → neil
Status: REOPENED → ASSIGNED
Attached patch Possible patchSplinter Review
I think it's better to control this from the noautohide attribute. This also means that I now Detach both ways. I've also excluded this on GTK since that won't work properly.
Attachment #8690918 - Attachment is obsolete: true
Attachment #8699074 - Flags: review?(enndeakin)
Attachment #8699074 - Flags: review?(enndeakin) → review+
https://hg.mozilla.org/mozilla-central/rev/fa802cc2231d
Status: ASSIGNED → RESOLVED
Closed: 11 years ago4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla47
Thank you! This was really important for us.
You need to log in before you can comment on or make changes to this bug.