Closed Bug 390178 Opened 14 years ago Closed 14 years ago
Can't focus elements within panel popup with the mouse if noautohide attribute is set to true
583 bytes, application/vnd.mozilla.xul+xml
1.50 KB, patch
|Details | Diff | Splinter Review|
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; sl; rv:22.214.171.124) Gecko/20070713 Firefox/126.96.36.199 Build Identifier: xulrunner 1.9a7 If i set the panels noautohide attribute to true, i can't focus elements within panel with the mouse. Cahnging focus with tab works ok. Reproducible: Always Steps to Reproduce: 1.Create a panel with some children elements. Include a textbox element. 2.Set the panels noautohide attribute to true. 3. Actual Results: Textbox within panel can't be focused with the mouse. Expected Results: Textbox within panel should be focused with the mouse.
Component: XP Toolkit/Widgets: XUL → XP Toolkit/Widgets: Menus
This is a Windows only issue right? I think this is possibly caused by the same issue as 390197 which is because the focus switches back to the main window again when clicking.
Status: UNCONFIRMED → NEW
Ever confirmed: true
It is a windows issue yes. I'll try it on linux and post the results.
It works on linux.
Flags: blocking1.9? → blocking1.9+
Priority: -- → P3
Is this still an issue? It's possible that bug 395334 fixed this.
I can't reproduce this (on Vista); I am able to focus the textbox in the panel that pops up with my mouse (if I have understood correctly :) Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b3pre) Gecko/2007121305 Minefield/3.0b3pre ID:2007121305
OK, so this is still an issue. The only way to fix this is to make the popups become activated, which has the unfortunate side effect of deactivating the parent. Unfortunately, Windows doesn't send mouse events to windows unless they are activated.
This is the patch that would be used to allow activating popups (which also fixes bug 385609). We may want to make this Windows only though, as it causes the active window to shift on other platforms. This is particularly an issue on Mac where the customize toolbar panel requires a click to activate first before dragging an item.
Neil, Could you review this bug? This is still issue on beta 5.
Tried, but can't make a test for this currently as relies on native events.
Status: NEW → ASSIGNED
Attachment #313421 - Flags: superreview?(roc) → superreview+
Attachment #313421 - Flags: review?(jmathies) → review?(roc)
Attachment #313421 - Flags: review?(roc) → review+
Comment on attachment 313421 [details] [diff] [review] This seems to work. Don't activate anything when clicking with the mouse Want to get this in for 1.9 as it makes the noautohide panels (like the customize toolbar dialog on Mac) not as generally useful as the mouse doesn't work on Windows. Can't find a means of testing this as it touches widget code but it doesn't affect anything except noautohide popups.
Attachment #313421 - Flags: approval1.9?
This is a blocker for the Firefox Companion for eBay, as our alert popups are noautohide panels :(
Comment on attachment 313421 [details] [diff] [review] This seems to work. Don't activate anything when clicking with the mouse a1.9=beltzner
Attachment #313421 - Flags: approval1.9? → approval1.9+
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
FWIW, I now can click on element belonging to a panel with noautohide, thanks :) (I put the statusbar in a noautohide popup and was unable to click on SB icons) Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008040907 Minefield/3.0pre ID:2008040907
Will this be released in Firefox 3.0 Release candidate version?
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: xptoolkit.xul → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.