The default bug view has changed. See this FAQ.

Can't scroll overflowing popup using keyboard, scrollwheel or trackpad

RESOLVED WONTFIX

Status

()

Core
XUL
RESOLVED WONTFIX
5 years ago
5 years ago

People

(Reporter: jorgev, Unassigned)

Tracking

({addon-compat, regression, testcase})

unspecified
x86
Mac OS X
addon-compat, regression, testcase
Points:
---

Firefox Tracking Flags

(firefox8 unaffected, firefox9+)

Details

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
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.

Updated

5 years ago
tracking-firefox9: ? → +

Comment 1

5 years ago
Neil, can you check the seriousness of this in the next 24 hours?  We need to know if re-spinning FF9 is required.

Comment 2

5 years ago
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.

Comment 4

5 years ago
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.
(Reporter)

Comment 5

5 years ago
(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?

Comment 6

5 years ago
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.
Blocks: 678834
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.
(Reporter)

Comment 8

5 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.