1017864 - <select> dropdown arrow showing alongside the background image that's intended to be taking its place, at accounts.firefox.com

Status: RESOLVED FIXED

(Cloud Services :: Server: Firefox Accounts, defect)

Description

[John Gruen [:jgruen]]

Attachment: select-ui-regression.png

Currently affecting Firefox Accounts (and I imagine a lot of other sites) in Firefox 30. 

Though this was resolved by comment 23 of: https://bugzilla.mozilla.org/show_bug.cgi?id=990655 but that isn't the case.

Comment 1

[Daniel Holbert [:dholbert] (PTO until 2/24)]

(In reply to John Gruen from comment #0)
> Though this was resolved by comment 23 of:
> https://bugzilla.mozilla.org/show_bug.cgi?id=990655 but that isn't the case.
(For future reference: "bug 990655 comment 23" will auto-linkify to that comment on that bug.)

Comment 2

[Daniel Holbert [:dholbert] (PTO until 2/24)]

I can reproduce this on Linux Nightly, too.

32.0a1 (2014-05-29)
Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 Firefox/32.0

I can't reproduce in Firefox release (version 29). This seems likely to be a regression from bug 963970; tentatively marking as-such.

Comment 3

[Mats Palmgren (inactive)]

This is an intentional change.  Before bug 990655, text-overflow:"" could be used
to clip away the combobox dropdown button.  That should never have been possible.

Comment 4

[Daniel Holbert [:dholbert] (PTO until 2/24)]

We should fix Firefox Accounts, then. (How should they be clipping away the dropdown button?)

This affects the in-app Accounts sign-up UI, too ( about:accounts?action=signup , which loads https://accounts.firefox.com/signup in an iframe.)

Comment 5

[Mats Palmgren (inactive)]

(In reply to Daniel Holbert [:dholbert] from comment #4)
> (How should they be clipping away the dropdown button?)

Well, that seems like a bad idea in the first place.
A combobox should have the appearance of a combobox so that
the user knows how to interact with it.

Can the page authors explain what they are trying to achieve
so that we can fix that instead?

Comment 6

[John Gruen [:jgruen]]

(In reply to Mats Palmgren (:mats) from comment #5)
> (In reply to Daniel Holbert [:dholbert] from comment #4)
> > (How should they be clipping away the dropdown button?)
> 
> Well, that seems like a bad idea in the first place.
> A combobox should have the appearance of a combobox so that
> the user knows how to interact with it.
> 
> Can the page authors explain what they are trying to achieve
> so that we can fix that instead?

We're trying to style a select element to match the overall UI on our page which is a Mozilla/Fireofox product page. In Firefox 29, we use a set of CSS rules to override default browser styles for the <select> element. In FF 30, these overrides no longer function. This appears to be a wider problem blocking the customization of <select> elements. 

Here's a very bare bones page demonstrating the issue. It looks as it should in 29 but doesn't look right in 30: http://people.mozilla.org/~jgruen/select_demo/

Comment 7

[Alex Henrie]

Is this a duplicate of bug 649849?

Comment 8

[Daniel Holbert [:dholbert] (PTO until 2/24)]

Not quite a duplicate; this behavior-change happened recently.

But, yes -- it sounds like bug 649849 is the platform bug that covers the feature that this page *really* wants to be using.

Comment 9

[Daniel Holbert [:dholbert] (PTO until 2/24)]

(And I guess this is the same as the "workaround no longer working" issues reported in bug 649849 comment 93, 95, and beyond.)

Anyway: even if we somehow fixed bug 649849 right now, there's no way we could backport the fix to Firefox 30, since Firefox 30 is late-beta at this point and only super-safe stuff will be approved.

SO: for Firefox Accounts, we need to do something to address this on the server-side (which could just be "use the platform native <select> dropdown without attempting to hide its downarrow", as an easy strawman solution to fall back on). Otherwise, Firefox 30 release users will end up hitting this when they sign up for Firefox Accounts.

Comment 10

[Lukas Blakk [:lsblakk] use ?needinfo]

Will track this for FF31 so we can work on having something ready in the next cycle, as it is too late for FF30.

Comment 11

[Sylvestre Ledru [:Sylvestre]]

Too late also for 31 now.

Comment 12

[Lawrence Mandel [:lmandel] (use needinfo)]

I spoke with Jet about bug 649849, which will come at some point but not likely before 34. If this bug is to be fixed before then, it will need to be worked around on the Firefox Accounts side. AFAIK, the fix is therefore going to be server side. As such, I am marking as tracking- but would like to know if there is any intention to fix this issue or if this bug should be resolved as won't fix.

jgruen - Can you help out with the next steps from the Firefox Accounts perspective?

Comment 13

[John Gruen [:jgruen]]

(In reply to Lawrence Mandel [:lmandel] from comment #12)
> I spoke with Jet about bug 649849, which will come at some point but not
> likely before 34. If this bug is to be fixed before then, it will need to be
> worked around on the Firefox Accounts side. AFAIK, the fix is therefore
> going to be server side. As such, I am marking as tracking- but would like
> to know if there is any intention to fix this issue or if this bug should be
> resolved as won't fix.
> 
> jgruen - Can you help out with the next steps from the Firefox Accounts
> perspective?

We did a CSS hack to hide the default control on FxA. I'm happy to let this bug close.

Comment 14

[Lawrence Mandel [:lmandel] (use needinfo)]

WFM. Marking as fixed. If you have it handy, perhaps you can mark this as a dup of the bug in which you added the CSS hack.

Comment 15

[John Gruen [:jgruen]]

Fixed here: https://github.com/mozilla/fxa-content-server/pull/1186

:lmandel not sure if I can mark a dupe here b/c Github.