Created attachment 575590 [details] Test case add-on This is regression from Firefox 8 to Firefox 9. Steps to reproduce: 1) Install attached add-on. 2)Customize toolbar to move the Test Case button into the main toolbar. 3) Click on the button. A popup with a scrollbar should appear. This is a XUL menupopup attached to a toolbarbutton. 4) Attempt to scroll on it using the keyboard arrows, mouse scrollwheel or trackpad. Expected results: The content scrolls. Observed results: The content doesn's scroll at all. The only way to scroll is to use the scrollbar. Tested on Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20100101 Firefox/9.0. I haven't tested this on other platforms.
Neil, can you check the seriousness of this in the next 24 hours? We need to know if re-spinning FF9 is required.
Actually add Neil to answer the question.
I don't think this menupopup is constructed the way a XUL menupopup should be constructed, and so this is just bad XUL: because it does not contain any <menuitems>, the keyboard focus isn't set to any elements when the popup is opened, which means that the keyboard focus stays with the page. Note that this does work correctly for menu popups that do use <menuitem>s, such as the tab list dropdown, so I feel that this is definitely not a release blocker, and is probably completely INVALID.
Is this testcase from some add-on? The testcase should be using <panel> not <menupopup> since the content in it isn't menu-related; making such a change causes it to work.
(In reply to Neil Deakin from comment #4) > Is this testcase from some add-on? The testcase should be using <panel> not > <menupopup> since the content in it isn't menu-related; making such a change > causes it to work. Yes, it is a simplified testcase from an existing add-on. The original request was posted here: http://blog.mozilla.com/addons/2011/10/11/compatibility-for-firefox-9/comment-page-1/#comment-154715 Do we know what changed in Firefox 9 that triggered this?
This was caused by bug 678834. Note that Benjamin's assessment above isn't quite correct. The keyboard focus doesn't affect scrollwheel behaviour on Mac. Scrolling occurs based on what the mouse is over. In this case, there are two scrollable areas, one a vbox made scrollable in the test and the other the anonymous arrowscrollbox provided by the menupopup. I think one of the scrollwheel events being cancelled prevents the other from firing, but Markus would be better positioned to explain if there is a real bug here. The addon author should still fix his addon though.
So the question is whether we want to support nested scrolling inside a <scrollbox>. I think it's not worth it, unless there's evidence that this case occurs more often in the wild. The fix for the add-on side here (replace <menupopup> by <panel>) is really simple.
I've only seen this add-on doing this, so I don't expect many cases presenting this problem. If it's not worth fixing, then I think we should just WONTFIX this. Either way, I'll tell the developer to use a panel instead.