990655 - In <select> element (combobox) w/ padding & text-overflow, dropdown arrow is missing at larger zoom levels, visible at lower ones

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, defect)

Description

[John Gruen [:jgruen]]

Attachment: 90-percent-zoom

<select> element UI can be overwritten with CSS, but if the browser is zoomed out, the UI reverts to default.

Comment 1

[John Gruen [:jgruen]]

Attachment: 100-percent-zoom

Comment 2

[John Gruen [:jgruen]]

see attachment for examples.

Below is the computed CSS for the <select> in the attached images.

background-attachment: scroll;
background-clip: border-box;
background-color: #F2F2F2;
background-image: url('http://localhost:3030/images/ddarrow_active.png');
background-origin: padding-box;
background-position: 96% 50%;
background-repeat: no-repeat;
background-size: 10px 17px;
border-bottom-color: #424F59;
border-bottom-left-radius: 5px;
border-bottom-right-radius: 5px;
border-bottom-style: solid;
border-bottom-width: 1px;
border-image-outset: 0 0 0 0;
border-image-repeat: stretch stretch;
border-image-slice: 100% 100% 100% 100%;
border-image-source: none;
border-image-width: 1 1 1 1;
border-left-color: #424F59;
border-left-style: solid;
border-left-width: 1px;
border-right-color: #424F59;
border-right-style: solid;
border-right-width: 1px;
border-top-color: #424F59;
border-top-left-radius: 5px;
border-top-right-radius: 5px;
border-top-style: solid;
border-top-width: 1px;
box-shadow: #F2F2F2 0px 1px 1px 0px inset;
box-sizing: border-box;
color: #8A9BA8;
font-family: "Clear Sans","Helvetica Neue",Helvetica,Arial,sans-serif;
font-size: 18px;
height: 48.5px;
margin-bottom: 0px;
margin-left: 0px;
margin-right: 0px;
margin-top: 0px;
outline-color: #8A9BA8;
outline-style: none;
outline-width: 0px;
padding-bottom: 10px;
padding-left: 20px;
padding-right: 20px;
padding-top: 10px;
text-align: start;
text-indent: 0.0166667px;
text-overflow: "";
text-transform: none;
transition-duration: 0.15s;
transition-property: all;
width: 340px;
-moz-appearance: none;
-moz-border-bottom-colors: none;
-moz-border-left-colors: none;
-moz-border-right-colors: none;
-moz-border-top-colors: none;

Comment 3

[Daniel Holbert [:dholbert]]

(In reply to John Gruen from comment #2)
> -moz-appearance: none;

Zooming isn't what gives us the default UI. ^^ This "-moz-appearance" is what gives us the default UI. (modulo your other style tweaks)

What you're seeing is that at 100% zoom level, the downarrow doesn't seem to be visible due to some combination of your other styles (text-overflow and padding-right, AFAICT), but it becomes visible at lower zoomlevels. Not sure why.

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: testcase 1: Empty & non-empty <select> tags

The arrow only seems to appear in <select> tags that have contents.

(i.e. in an empty <select></select> tag, the downarrow doesn't appear when I zoom out, at least on my system)

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (simpler, only an empty <select> element)

(In reply to Daniel Holbert [:dholbert] from comment #4)
> The arrow only seems to appear in <select> tags that have contents.
> 
> (i.e. in an empty <select></select> tag, the downarrow doesn't appear when I
> zoom out, at least on my system)

Ah, this was a red herring -- it's just an artifact of the amount of padding I was using (which was probably pushing the downarrow out of view).

Here's a simplified testcase with only "padding-right:1px", which makes this reproduce even in an empty <select>.

Comment 6

[Daniel Holbert [:dholbert]]

Attachment: testcase 3: using an explicit character ("*") for text-overflow)

Here's a testcase with an actual character "*" for text-overflow.

I think what's happening is that we're treating the components of <select> (the button in particular) as an overflowing inline element -- overflowing because of the padding -- which makes us hide it and replace it with the contents of the "text-overflow" property.

Not sure why the zoom level affects this, though. (I could imagine it being a rounding issue if this only happened with 1px of padding, but as testcase 1 shows, this happens with larger amounts of padding as well.)

Comment 7

[Daniel Holbert [:dholbert]]

(Side note: anyone who hits this bug *really* probably wants to be styling the <select> dropdown arrow directly, rather than trying to make it invisible with "text-overflow" hacks. Bug 649849 tracks the ability to do that.)

Comment 8

[Mats Palmgren (inactive)]

It shouldn't be possible to remove the <select>'s drop-down button using text-overflow.
That's just a bug we should fix.  It seems to be a recent regression - I can reproduce it
in Aurora but not Beta.  Perhaps caused by bug 963970?

Comment 9

[Mats Palmgren (inactive)]

After looking at the frame dumps it's pretty clear the drop-down button is placed
in the padding area, so technically it always overflows when there's right padding.
That's true also without zooming but there's an optimization in the text-overflow
code that skips analyzing the frame tree when the line box doesn't overflow,
which it apparently is true without zoom but not otherwise (not sure why).

I guess one workaround would be to just ignore nsComboboxControlFrame in the
text-overflow code, since we know what we really want in this case is for its
anonymous block (that inherits text-overflow) to deal with it.

We could also make nsComboboxControlFrame not inherit nsBlockFrame but that's
more work.

Placing the (normal flow) button child frame outside the content area might be
hard to maintain in the long run though.  I just tried "overflow-clip-box:content-box"
and it clips the button, for example.

Comment 10

[Sebastian Zartner [:sebo]]

(In reply to Daniel Holbert [:dholbert] from comment #3)
> (In reply to John Gruen from comment #2)
> > -moz-appearance: none;
> 
> Zooming isn't what gives us the default UI. ^^ This "-moz-appearance" is
> what gives us the default UI. (modulo your other style tweaks)

To clarify this, this bug is independent of '-moz-appearance' being set to 'none'. It also happens when using the OS styling. (At least on Win7.) So the bug summary should be changed to reflect that.

Sebastian

Comment 11

[Daniel Holbert [:dholbert]]

True -- in particular: on Win7, the (native-look) dropdown arrow is visible/invisible at different zoom levels, even with the "-moz-appearance:none" styling removed, according to my testing just now with a local variant of testcase 3. I had to zoom in a bit to make the dropdown arrow disappear, though -- it was visible at the default zoom level.
 --> generifying bug summary.

Comment 12

[Alex Henrie]

Confirmed regression.

The first bad revision is:
changeset:   172552:cfbcdc591ccd
user:        Alex Henrie <[e-mail]>
date:        Thu Mar 06 16:24:01 2014 -0700
summary:     Bug 963970 - Place combobox button where a scrollbar would be. r=roc

http://hg.mozilla.org/mozilla-central/rev/cfbcdc591ccd

Comment 13

[Alex Henrie]

(In reply to Mats Palmgren (:mats) from comment #9)
> Placing the (normal flow) button child frame outside the content area might
> be hard to maintain in the long run though.  I just tried
> "overflow-clip-box:content-box" and it clips the button, for example.

Yeah, that's a good point. I don't really know how to do this, but it seems to me that the ideal solution would be to treat <select> like <span><dropdown><button></span> and forward the padding to <dropdown> similar to what <textarea> does with its anonymous child (bug 157846). Otherwise overflow-clip-box will stay broken and we're likely to run into other problems in the future as well.

Comment 14

[Mats Palmgren (inactive)]

Attachment: fix+reftest

https://tbpl.mozilla.org/?tree=Try&rev=c9602df90656
https://tbpl.mozilla.org/?tree=Try&rev=1d081624c6de

Comment 15

[Mats Palmgren (inactive)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/b5c7349ece19

Comment 16

[Alex Henrie]

Mats, does that commit fix the problem with "overflow-clip-box:content-box"? If not, could you post an example of the problem?

Comment 17

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/b5c7349ece19

Comment 18

[Mats Palmgren (inactive)]

(In reply to Alex Henrie from comment #16)
> Mats, does that commit fix the problem with "overflow-clip-box:content-box"?
> If not, could you post an example of the problem?

I filed bug 992447.

Comment 19

[Mats Palmgren (inactive)]

Comment on attachment 8401072 [details] [diff] [review]
fix+reftest

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 963970
User impact if declined: layout regression for zoomed comboboxes that use 'text-overflow'
Testing completed (on m-c, etc.): on m-c since 2014-04-04
Risk to taking this patch (and alternatives if risky): low risk 
String or IDL/UUID changes made by this patch: none

Comment 20

[Sebastian Zartner [:sebo]]

Attachment: Drop-down arrow not displayed for default zoom level

Note that 'testcase 1' is still failing (at least on Win7) for some zoom levels including the default zoom level.

In the attached screenshot the drop marker is not shown until you reach a specific larger zoom level.

Sebastian

Comment 21

[Lukas Blakk [:lsblakk] use ?needinfo]

Comment on attachment 8401072 [details] [diff] [review]
fix+reftest

Do any changes need to happen here regarding comment 20? or will that be a follow up/separate bug?

Comment 22

[Mats Palmgren (inactive)]

Thanks Sebastian, it looks like an unrelated problem (it also occurs without 'text-overflow').

Lukas, no, I filed bug 994726 about it.

Comment 23

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/86a35aa4500d

Comment 24

[John Gruen [:jgruen]]

Attachment: Screen Shot 2014-05-29 at 5.07.28 PM.png

This screenshot was taken today on accounts.firefox.com using Firefox 30 on OSX. Is the fix for this bug being uplifted before release?

Comment 25

[Daniel Holbert [:dholbert]]

Comment 23 was supposed to have fixed this for Firefox 30.

I can reproduce what's shown in your screenshot, in a Firefox 30 build as well as a Nightly build, so it's different from this bug. (And it does seem to be a regression -- I can't reproduce it in Firefox 29.)

Could you file a new bug on it? (though perhaps it's related to the bug spun off in comment 22?)

Comment 26

[John Gruen [:jgruen]]

(In reply to Daniel Holbert [:dholbert] from comment #25)
> Comment 23 was supposed to have fixed this for Firefox 30.
> 
> I can reproduce what's shown in your screenshot, in a Firefox 30 build as
> well as a Nightly build, so it's different from this bug. (And it does seem
> to be a regression -- I can't reproduce it in Firefox 29.)
> 
> Could you file a new bug on it? (though perhaps it's related to the bug spun
> off in comment 22?)

Filed this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1017864