Lengthy text in an option breaks rendering of select box

RESOLVED WORKSFORME

Status

()

P4
minor
RESOLVED WORKSFORME
3 years ago
a year ago

People

(Reporter: swayam, Unassigned)

Tracking

({regression, testcase})

42 Branch
regression, testcase
Points:
---

Firefox Tracking Flags

(e10s-)

Details

(Whiteboard: tpi:+, URL)

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
Created attachment 8695776 [details]
Annotated screenshot of the bug

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:41.0) Gecko/20100101 Firefox/41.0
Build ID: 20150917150946

Steps to reproduce:

1. Create a select box with multiple options
2. Have one option with over two thousand characters in its text
3. Click on the select box
4. Clicking on any option in an area towards the left of the select box


Actual results:

1. The list of options increases in length on both the left and the right of the select box

2. Clicking any option in an area towards the left of the select box closes the options list without setting the select box to the option

2. Clicking any option in an area towards the right of the select box sets the select box to the option




Expected results:

1. The list of options increases in length only towards the right of the select box
2. Clicking any option in any area sets the select box to the option


Notes:
The behaviour can be experimented with here:
http://scratchpad.io/terrific-station-3670

I've created two boxes, one with regular sized options and one with a really large option.

Comment 1

3 years ago
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:42.0) Gecko/20100101 Firefox/42.0
20151029151421
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:43.0) Gecko/20100101 Firefox/43.0
20151201152349

The select box expands off-screen, but only on the right side. Clicking either side of the option works properly.

Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:44.0) Gecko/20100101 Firefox/44.0
20151203004003

With e10s enabled, clicking either select element does nothing.
With e10s disabled, same behavior as release and beta.

Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:45.0) Gecko/20100101 Firefox/45.0
20151203053521

With e10s enabled, the select box expands to fill the screen in both directions. On the right side, the string is truncated with an ellipsis. Clicking either side of the option works properly.
With e10s disabled, same behavior as release and beta.
Component: Untriaged → Layout: Form Controls
Keywords: testcase
Product: Firefox → Core

Updated

3 years ago
tracking-e10s: --- → ?
On Mac, I can confirm the problem almost as reported, in non-e10s mode, in 41, 42, and nightly.  Clicking on the left-ish side of the options in the dropdown doesn't select them (but also doesn't close the dropdown, for me).

Mats, any idea what's going on here?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(mats)
The testcase works fine on Linux, in non-e10s mode, and I don't see any assertions in a debug build.
So it might be Widget:Cocoa bug?
Severity: normal → minor
Component: Layout: Form Controls → Widget: Cocoa
Flags: needinfo?(mats)
> So it might be Widget:Cocoa bug?

Could be.  In a debug build I see no anything when clicking on the left side there; just no response....
George, is this a dupe?
Flags: needinfo?(gwright)
Don't think so, but this appears to be non-e10s only? I can't reproduce on OS X nightly with e10s.
Flags: needinfo?(gwright)
this is non-e10s. Is it a recent regression?
tracking-e10s: ? → -
Keywords: regressionwindow-wanted
For what it's worth, I can reproduce this bug on Firefox 42.0, so it doesn't seem that recent to me.
I see from comment 2 that it dates from at least 41
Basically, it appears that the dropdown menu used to be left-aligned with the edge of the select box when things worked correctly, then it regressed when the dropdown menu positioning changed to take up the whole screen. The dividing line between clicking working and not working remains the left edge of the select box.

Regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=895f66c4eada&tochange=85f561c755f6

Too old for inbound bisection. While DLBI (or one of the patches that landed alongside it) makes for a good candidate, bug 674373 seems more likely. I suppose it would be interesting to test this on a non-Retina Mac and see what happens.
Flags: needinfo?(jfkthame)
Keywords: regressionwindow-wanted → regression
I don't think retina vs non-retina makes any difference here; or at least, opening Nightly in low-res mode (on my retina Mac) still shows the same behavior. It does seem likely that bug 674373 is involved, though, as the patches there will have touched codepaths that are relevant to popup placement and event handling regardless of the resolution.

I'll leave needinfo? on myself to remind me to look into this, but won't have time in the immediate future; so if someone else has a chance to dig in, please feel free to go ahead!
Priority: -- → P4
Whiteboard: tpi:+
Stephen, maybe you'd be interested in taking a look? :)
Flags: needinfo?(spohl.mozilla.bugs)
I thought I could reproduce this a few weeks ago, but I can no longer reproduce with a recent local build from m-c. Can anyone still reproduce in a recent nightly?
Flags: needinfo?(spohl.mozilla.bugs)
WFM based on comment 13. Feel free to reopen if you can still reproduce.
Status: NEW → RESOLVED
Last Resolved: a year ago
Flags: needinfo?(jfkthame)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.