Open Bug 1287227 Opened 8 years ago Updated 4 months ago

Very long <option>s can't be clicked on to the left of the <select>


(Core :: Layout, defect, P3)

47 Branch




(Reporter: josh, Unassigned)





(3 files)

Attached image dropdown.png
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36

Steps to reproduce:

1. Load a page with a <select> that has very long answer options. (Example:

2. Click on the <select>, move your mouse to the left of the <select> width, and then move down to try selecting an option.

Actual results:

The option isn't selected. The user must click the option directly under the <select>, or to the right of the <select>, for their click to register.

Expected results:

The user should be able to click anywhere in the <option> to select it.
OS: Unspecified → Mac OS X
Hardware: Unspecified → x86_64
Component: Activity Streams: General → DOM
Product: Firefox → Core
It seems it's not reproducible on Windows. Is it specific to Mac OSX?
Flags: needinfo?(josh)
Component: DOM → Layout
Two employees and one customer of my company have reproduced it on OS X. None of us have Windows machines.
Looks like it's an old issue.

There was a behavior change in 19.0a1, in the following range:

the dropdown menu was using only right side, and it's expanded to left side, but the expanded part doesn't accept click.
The box of the option element seems to be related.

with the original testcase, the box of the option element doesn't cover left side, and you can click the lightblue area only.

when I add the following style to the testcase:
  option {
    margin: -200px;
the box of the option is shifted to right side, and you can still click lightblue area only, but this expands the clickable area 200px to left.

So, looks like there's mismatch between the displayed menu and actually clickable element behind it.
I'm guessing this is caused by bug 794038 from the regression range. The popup location actually moves. So maybe the "contrain to screen" logic is affecting the position, but the display list/hit testing don't take this into account.
Blocks: 794038
Ever confirmed: true
This sounds a lot like bug 1230467. Is it limited to non-e10s?
(In reply to Jonathan Kew (:jfkthame) from comment #6)
> This sounds a lot like bug 1230467. Is it limited to non-e10s?

Priority: -- → P3
Severity: normal → S3

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit BugBot documentation.

Flags: needinfo?(josh)
You need to log in before you can comment on or make changes to this bug.