The default bug view has changed. See this FAQ.

[e10s] Properly style <option> elements in the parent process UI (support color and background on select options)

RESOLVED FIXED in Firefox 54

Status

()

Core
Layout: Form Controls
P1
normal
RESOLVED FIXED
4 years ago
13 hours ago

People

(Reporter: Felipe, Assigned: Jared Beach)

Tracking

(Depends on: 1 bug, Blocks: 5 bugs, {dev-doc-needed})

Trunk
mozilla54
dev-doc-needed
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(e10s+, firefox52+ wontfix, firefox53+ fix-optional, firefox54 fixed, firefox-esr52 affected)

Details

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(3 attachments)

(Reporter)

Description

4 years ago
In bug 897060 we implemented support for displaying the dropdowns from <select> widgets in the parent, by opening a menupopup filled with menuitems equivalent to the content from the <option> <optgroup> children elements from the <select> widget.

However, the rendering is not equivalent because the CSS styles that affect the rendering of these elements are not passed to the parent.

Not every CSS property is supported in them, but several are, such as: color, background-color, margins, paddings, font, font-size, font-weight, text-decoration, etc. (p.s. I don't know where to find the exhaustive list)

There are some non-straightforward issues to solve, such as:
 - :hover style
 - figure out if we want native menupopup look, or native dropdown look
 - if we want native menu look, we need to take care of the default styles which are different between <option> and <menuitem>
 - big messages through the message manager are not cheap, so it's probably not good to send all computed styles for every item and every supported CSS property
(Reporter)

Updated

4 years ago
Blocks: 910023
(Reporter)

Comment 1

4 years ago
This bug also blocks bug 910022 for reasons explained in bug 910022 comment 0 part (3)
Webkit/Blink support minimal styling of the options --- text color/background color of each option and the background of the dropdown, and that's about it. And note that when we display the currently selected item in the <select> element itself, that uses none of the option's styles. So I don't think we need to do much here; I'd be fine to limit to what Webkit/Blink support.

I didn't test whether they support :hover or other psuedostyles on <option>s.

I think taking this opportunity to go for a clean break and use native dropdowns (or native look-and-feel with a XUL-based implementation) might be a good idea.
tracking-e10s: --- → +
tracking-e10s: + → later

Updated

2 years ago
Duplicate of this bug: 1112381

Updated

2 years ago
See Also: → bug 1128159

Updated

2 years ago
Blocks: 1154677

Updated

2 years ago
Duplicate of this bug: 1173062

Updated

2 years ago
Duplicate of this bug: 1196892

Updated

2 years ago
Duplicate of this bug: 1185394

Updated

2 years ago
Summary: [e10s] Properly render <option> elements in the parent process UI → [e10s] Properly style <option> elements in the parent process UI

Updated

2 years ago
Duplicate of this bug: 1200751

Updated

2 years ago
Blocks: 1194700

Comment 8

2 years ago
Could you please rethink not fixing this bug before releasing e10s? It will break many sites and I don't believe that any web developer is aware of this…

Updated

2 years ago
Duplicate of this bug: 1205718
Note that there are other rendering problems this causes because the XUL styling doesn't match the expected styling even in the absence of website styles.  See bug 1208297.
Blocks: 1208297

Updated

a year ago
Blocks: 1238499
Can someone confirm that bug 1196892 is indeed a duplicate of this one?
And if yes, explain why. To remove all doubts due to misunderstanding.

Updated

a year ago
Blocks: 1197942

Updated

a year ago
tracking-e10s: later → +
Flags: needinfo?(jgriffiths)
Priority: -- → P1

Updated

a year ago
Duplicate of this bug: 1197942
Duplicate of this bug: 1256708
Jim: I think we need to get more info on this bug, for example what the engineering effort would be to mimic blink/webkit's level of support as roc mentions:

(In reply to Robert O'Callahan (:roc) (Exited; email my personal email if necessary) from comment #2)
> Webkit/Blink support minimal styling of the options --- text
> color/background color of each option and the background of the dropdown,
> and that's about it. And note that when we display the currently selected
> item in the <select> element itself, that uses none of the option's styles.
> So I don't think we need to do much here; I'd be fine to limit to what
> Webkit/Blink support.
> 
> I didn't test whether they support :hover or other psuedostyles on <option>s.
> 
> I think taking this opportunity to go for a clean break and use native
> dropdowns (or native look-and-feel with a XUL-based implementation) might be
> a good idea.
Flags: needinfo?(jgriffiths) → needinfo?(jmathies)
(In reply to Jeff Griffiths (:canuckistani) (:⚡︎) from comment #14)
> Jim: I think we need to get more info on this bug, for example what the
> engineering effort would be to mimic blink/webkit's level of support as roc
> mentions:
> 
> (In reply to Robert O'Callahan (:roc) (Exited; email my personal email if
> necessary) from comment #2)
> > Webkit/Blink support minimal styling of the options --- text
> > color/background color of each option and the background of the dropdown,
> > and that's about it. And note that when we display the currently selected
> > item in the <select> element itself, that uses none of the option's styles.
> > So I don't think we need to do much here; I'd be fine to limit to what
> > Webkit/Blink support.
> > 
> > I didn't test whether they support :hover or other psuedostyles on <option>s.
> > 
> > I think taking this opportunity to go for a clean break and use native
> > dropdowns (or native look-and-feel with a XUL-based implementation) might be
> > a good idea.

Personally I like the follow up idea roc has where he suggests we make a clean break and not support custom styling at all. If we add partial support we risk looking broken thanks to partial styling.

As far as level of effort goes, getting the background color and a font size over is probably pretty easy, getting that set on the new dropdown dealing with layout and alignment issues *might* take some tweaking once QA and users get a hold of this.

Also, If we do block on this I think we probably won't be able to uplift very far. I'd like to suggest making this +/P1 and kick off a discussion with web compat people and fx front end on what we want to support here first.
Flags: needinfo?(jmathies)
gwright, have you ever looked into shipping basic style info over for this? Wondering what the level of effort might be.
Flags: needinfo?(gwright)
We already send down some basic style info such as style.display. I think we opted not to support styling for the most part in e10s selects, especially as Chrome/Safari don't support it.

What info would we want to ship in a "basic style info" payload?
Flags: needinfo?(gwright)
(In reply to Jim Mathies [:jimm] from comment #15)
...
> Also, If we do block on this I think we probably won't be able to uplift
> very far. I'd like to suggest making this +/P1 and kick off a discussion
> with web compat people and fx front end on what we want to support here
> first.

Seems reasonable.
Duplicate of this bug: 1291544
If we don't support styling for selects, shouldn't we do it for both e10s and non-e10s selects? And/or document it somewhere?
Not sure what is the best place to document this kind of things? Maybe a note on MDN (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/option)?

A user was confused by this change (https://bugzilla.mozilla.org/show_bug.cgi?id=1291306#c6) and I spent quite some time understanding why this was only working on FF48 for me, not finding any documentation about a change on <option> styling. And e10s is not the first thing you think about when investigating a styling issue.

Jeff: what do you think about this?
Flags: needinfo?(jgriffiths)
(In reply to Julian Descottes [:jdescottes] from comment #20)
> If we don't support styling for selects, shouldn't we do it for both e10s
> and non-e10s selects? And/or document it somewhere?
> Not sure what is the best place to document this kind of things? Maybe a
> note on MDN
> (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/option)?
> 
> A user was confused by this change
> (https://bugzilla.mozilla.org/show_bug.cgi?id=1291306#c6) and I spent quite
> some time understanding why this was only working on FF48 for me, not
> finding any documentation about a change on <option> styling. And e10s is
> not the first thing you think about when investigating a styling issue.
> 
> Jeff: what do you think about this?

I'm not working directly on e10s currently and am not up to speed on what has been done with this issue. I assume that since this bug is still open nothing has been done yet, which is in line with the priority we assigned to it eg it did not block shipping e10s.

Jim: do you have an update on where we are with this?
Flags: needinfo?(jgriffiths) → needinfo?(jmathies)

Comment 22

7 months ago
documentation would be good. Layout will have to prioritize this work, the e10s team isn't going to work on it.
Flags: needinfo?(jmathies) → needinfo?(bugs)
Keywords: dev-doc-needed

Comment 23

7 months ago
If I read this bug correctly, there are two possible directions to a fix:
1. Match WebKit/Blink control styling behavior
   If we do this, we should spec it and enable the limited set of style options.
2. Render native or native-looking controls
   If we do this I think we should use real native controls. The maintenance burden of fake native controls seems too high.

In either case, I agree that it should be identical for e10s or non-e10s. 

mconley: what does Platform UX think?
Flags: needinfo?(bugs) → needinfo?(mconley)
(In reply to Jet Villegas (:jet) from comment #23)
> mconley: what does Platform UX think?

To be clear, I'm Platform UI - not UX. So my perspective is not coming from a design sense, but an engineering sense.

Above all, I think what we need to do here is be consistent. Right now, we have two completely different implementations for <select> dropdown - one for e10s, and one for non-e10s. We should try to combine these so that we only have a single codepath to worry about.

I'm in the camp that native look, feel and function is a great starting point for these controls, but if there are ways that we can improve upon them, we should consider it.

Perhaps not coincidentally, I'll be working with :jaws from the Firefox org and some MSU students to do the following in the Fall:

1) Combine the e10s and non-e10s <select> dropdown logic
2) Restyle the select dropdowns to adhere to this spec: https://bugzilla.mozilla.org/show_bug.cgi?id=1091592
3) Investigate and implement improvements to the dropdown, including (but not limited to) search capability for very long lists (see the spec at https://bug1091592.bmoattachments.org/attachment.cgi?id=8776005 for details).

With regards to styles coming up from content, WebKit parity (text colour and background colour) makes sense, so long as we're consistent.
Flags: needinfo?(mconley)
I think it's worth noting that Chrome isn't consistent between platforms. If I remember correctly, Chrome on OS X doesn't support styling at all (or a very limited amount) in select dropdowns, whereas on Windows it supports more.
Duplicate of this bug: 1298465

Updated

7 months ago
Duplicate of this bug: 1300749

Updated

6 months ago
Flags: a11y-review+

Updated

6 months ago
Flags: a11y-review+

Comment 28

6 months ago
I'm not sure of the nuts-and-bolts of this issue as discussed, but I can report that our office had no problem with this up through version 48.0.2. When 2 of the workstations got updated to 49.0, the text in the <option> tags shrunk to some unknown (12pt?) font size. Nothing I've tried will restore it to the same font size as the <select>. Only those users whose workstations (Windows 7, btw) are seeing this problem. Those still on 48.0.2 see the <option> font sizes correctly. Nor was there any such problem since we started using Firefox which was about 4 months ago. My conclusion is that something in the new release of 49.0 broke this.

Comment 29

6 months ago
Easy question: return support for styling selects?

Updated

6 months ago
Duplicate of this bug: 1305324

Updated

6 months ago
Duplicate of this bug: 1305408

Comment 32

6 months ago
(In reply to Mark Foley from comment #28)

> I'm not sure of the nuts-and-bolts of this issue as discussed, but I can
> report that our office had no problem with this up through version 48.0.2.
> ...
> My conclusion is that
> something in the new release of 49.0 broke this.

Our experience is exactly the same as Mark's.  We style some <option> elements with various background-color colors (nothing fancier), and this is no longer working for Firefox 49.0.1 on Windows 7.  (Firefox 49.0.1 on XP doesn't have the problem.)

Comment 33

6 months ago
(In reply to alex.sudakar from comment #32)
> (In reply to Mark Foley from comment #28)
> 
> > I'm not sure of the nuts-and-bolts of this issue as discussed, but I can
> > report that our office had no problem with this up through version 48.0.2.
> > ...
> > My conclusion is that
> > something in the new release of 49.0 broke this.
> 
> Our experience is exactly the same as Mark's.  We style some <option>
> elements with various background-color colors (nothing fancier), and this is
> no longer working for Firefox 49.0.1 on Windows 7.  (Firefox 49.0.1 on XP
> doesn't have the problem.)

Our experience is the same, we use styled options with different background colors.
But after some more testing I noticed Firefox isn't the only one, Chrome on Mac will also not show any styling. And if you have mobile users it getting worse.
Styling selects cross browser is really a nightmare:
https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Forms/Advanced_styling_for_HTML_forms#Dealing_with_the_select_nightmare

If you need styled options, you're best chance is to use a jQuery plugin (something like https://select2.github.io/), to replace the select.
This is currently the only way to get the same results cross-browser.

Comment 34

6 months ago
(In reply to info from comment #33)
> Styling selects cross browser is really a nightmare:

Styling HTML "form elements" of most kinds is a nightmare, and IMHO one of the big remaining pieces why HTML is still not a good UI language (and XUL still trumps it). I'd really wish TPTB in WHATWG/W3C would get that fixed by standards and implementations.

Comment 35

6 months ago
Well I always thought styling <select> element would work since I've seen a lot sites do that, guess that's just because I'm on Windows all the time. So I did some Internet search and found this:

http://archivist.incutio.com/viewlist/css-discuss/39858
>The select element is part of the operating system, not the browser chrome.

IMHO, if that stands true, shouldn't Firefox just follow what the Browser comes with the OS does? Like Google Chrome: styles it on Windows (like IE), doesn't style it on OS X (like Safari)

Updated

6 months ago
Duplicate of this bug: 1308124
See Also: → bug 1308466
See Also: bug 1308466
Duplicate of this bug: 1308466
Summary: [e10s] Properly style <option> elements in the parent process UI → [e10s] Properly style <option> elements in the parent process UI (support color and background on select options)
Duplicate of this bug: 1308299

Comment 39

6 months ago
Created attachment 8799058 [details]
Firefox_39_Option.png

Why only  color and background ? I use also the border like separators.

For me, it is incomprehensible that we can not put HTML in <option> tags. Why ? It is more easier to rebuild a <select> with non-from elements.
See Also: → bug 1309652
See Also: → bug 1313132

Updated

5 months ago
Blocks: 1313402

Updated

5 months ago
Duplicate of this bug: 1314611

Updated

5 months ago
Duplicate of this bug: 1314611

Updated

5 months ago
Duplicate of this bug: 1314798

Updated

5 months ago
Duplicate of this bug: 1315401
Assignee: nobody → beachjar
Status: NEW → ASSIGNED
Duplicate of this bug: 1316272

Comment 45

4 months ago
Disappointing to see styling in select dropdowns no longer supported.  In some instances, it's quite impactful.

Updated

4 months ago
Duplicate of this bug: 1319377

Comment 47

4 months ago
Please remove also the ugly blue background-color appearing on mouse over disabled items.


Don't know if it is always possible, but if you could also support the ::before and ::after pseudo-elements, It will be useful to show icon on option.

This is the CSS style I use until now:
option.icon-sysUser::before {
    background-color: #CFC;
}
.icon-sysUser::before {
    background-position: -126px -378px;
}
option.icon::before {
    margin: 1px 3px 1px 0;
    background-image: url(/images/sprite.png);
    width: 18px;
    height: 18px;
    content: "";
    display: inline-block;
    vertical-align: middle;
    margin-right: 4px;
}
Comment hidden (mozreview-request)
Depends on: 1323618
(In reply to guerin45 from comment #47)
> Please remove also the ugly blue background-color appearing on mouse over
> disabled items.

This is already removed in Nightly. I can't reproduce this issue with the following web page:
data:text/html,<select><option disabled>test<option>test2<option>test3
 
> Don't know if it is always possible, but if you could also support the
> ::before and ::after pseudo-elements, It will be useful to show icon on
> option.

This isn't possible now and we don't have any plans to support it.

Comment 50

3 months ago
mozreview-review
Comment on attachment 8818718 [details]
Bug 910022 - Allow styling of <option> elements color & background color on windows

https://reviewboard.mozilla.org/r/98670/#review100232

I have updated beachjar's patch to work on top of the patch that I am implementing in bug 1323618. Once bug 1323618 lands then we can push forward on this one.
Attachment #8818718 - Flags: review?(jaws)

Updated

3 months ago
Duplicate of this bug: 1326571

Updated

3 months ago
Duplicate of this bug: 1328468

Comment 53

3 months ago
Here is a test case of the issues I am having http://jsfiddle.net/ovz4n1h8/
Blocks: 1331725

Comment 54

2 months ago
I've just upgraded to 51, but up to 50.1.0 e10s was disabled because of a couple of addons I use. Because this bug is very annoying for me (it's a major UI annoyance for the end users if you style options in select lists that are semantically different from one another), is there a way to disabled e10s in this new version? When will there be a fix for it?
Comment hidden (mozreview-request)
Comment hidden (mozreview-request)

Updated

2 months ago
Duplicate of this bug: 1334854
Comment on attachment 8830923 [details]
Bug 910022 - Allow websites to provide custom background colors and foreground colors for <select> popups.

https://reviewboard.mozilla.org/r/107588/#review109388

Tested this on OS X (after I applied my fix - see below). Thanks!

::: browser/base/content/test/general/browser_selectpopup.js:742
(Diff revision 2)
>    yield BrowserTestUtils.removeTab(tab);
>  });
>  
> +add_task(function* test_colors_applied_to_popup() {
> +  function inverseRGBString(rgbString) {
> +    let [, r, g, b] = rgbString.match(/^rgb\((\d+),\s*(\d+),\s*(\d+)\)$/);

Nit: I'm not the hugest fan of the `[, x, y, z]` pattern for dropping the first element. Not going to block on this, but I'd honestly prefer the more explicit:

`let [unused, r, g, b] = ...`

Feel free to drop though.

::: browser/base/content/test/general/browser_selectpopup.js:746
(Diff revision 2)
> +  function inverseRGBString(rgbString) {
> +    let [, r, g, b] = rgbString.match(/^rgb\((\d+),\s*(\d+),\s*(\d+)\)$/);
> +    return `rgb(${255 - r}, ${255 - g}, ${255 - b})`;
> +  }
> +
> +  const pageUrl = "data:text/html," + escape(PAGECONTENT_COLORS);

Can you avoid the escape by doing:

```
const pageUrl = `data:text/html,${PAGECONTENT_COLORS}`;
```

?

Also, should this be PAGE_URL?

::: browser/base/content/test/general/browser_selectpopup.js:765
(Diff revision 2)
> +    // We need to use Canvas here to get the actual pixel color
> +    // because the computedStyle will only tell us the 'color' or
> +    // 'backgroundColor' of the element, but not what the displayed
> +    // color is due to composition of various CSS rules such as
> +    // 'filter' which is applied when elements have custom background
> +    // or foreground elements.
> +    let canvas = document.createElementNS("http://www.w3.org/1999/xhtml", "canvas");
> +    canvas = document.documentElement.appendChild(canvas);
> +    let rect = child.getBoundingClientRect();
> +    canvas.setAttribute("width", rect.width);
> +    canvas.setAttribute("height", rect.height);
> +    canvas.mozOpaque = true;
> +
> +    let ctx = canvas.getContext("2d");
> +    ctx.drawWindow(window, rect.x + rect.left, rect.y + rect.top, rect.width, rect.height, "#000", ctx.DRAWWINDOW_USE_WIDGET_LAYERS);
> +    let frame = ctx.getImageData(0, 0, rect.width, rect.height);
> +
> +    let pixels = frame.data.length / 4;
> +    // Assume the inverse backgroundColor is the color of the first pixel.
> +    let [inverseBgR, inverseBgG, inverseBgB] = frame.data;
> +    let inverseBackgroundColor = `rgb(${inverseBgR}, ${inverseBgG}, ${inverseBgB})`;
> +    // Use the next different pixel color as the foreground color, assuming
> +    // no anti-aliasing.
> +    let inverseColor = inverseBackgroundColor;
> +    for (let i = 0; i < pixels; i++) {
> +      if (frame.data[i * 4 + 0] == 246) { alert("got toolbar color"); };
> +      if (inverseBgR != frame.data[i * 4 + 0] &&
> +          inverseBgG != frame.data[i * 4 + 1] &&
> +          inverseBgB != frame.data[i * 4 + 2]) {
> +        inverseColor = `rgb(${frame.data[i * 4 + 0]}, ${frame.data[i * 4 + 1]}, ${frame.data[i * 4 + 2]})`;
> +      }
> +    }

I feel like this is the sort of thing that makes for a good helper function, but it's not a strong feeling.

::: browser/base/content/test/general/browser_selectpopup.js:790
(Diff revision 2)
> +    let inverseBackgroundColor = `rgb(${inverseBgR}, ${inverseBgG}, ${inverseBgB})`;
> +    // Use the next different pixel color as the foreground color, assuming
> +    // no anti-aliasing.
> +    let inverseColor = inverseBackgroundColor;
> +    for (let i = 0; i < pixels; i++) {
> +      if (frame.data[i * 4 + 0] == 246) { alert("got toolbar color"); };

Leftover debugging?

::: toolkit/modules/SelectContentHelper.jsm:228
(Diff revision 2)
>                                : child.text;
>        if (textContent == null) {
>          textContent = "";
>        }
>  
> +      DOMUtils.addPseudoClassLock(child, ":checked", false);

Mind adding a comment here about how we're locking off the :checked pseudoclass so that we can get the true styles of the `selected` item?

::: toolkit/themes/osx/global/menu.css:138
(Diff revision 2)
>  menuitem[_moz-menuactive="true"] {
>    color: -moz-mac-menutextselect;
>    background-color: Highlight;
>  }
>  
> +menuitem[_moz-menuactive="true"][customoptionstyling="true"] {

At least for OS X, I think you're going to need to add this:

```css
menuitem[customoptionstyling="true"] {
  -moz-appearance: none;
  padding-top: 0px;
  padding-bottom: 0px;
}
```

The padding is optional, but it gets rid of space above the top element and below the bottom element which might clash with the background colours. If we don't care about that, you can get rid of that change. But the -moz-appearance is definitely necessary in order to be able to set the background colours.
Attachment #8830923 - Flags: review?(mconley) → review+

Comment 59

2 months ago
mozreview-review-reply
Comment on attachment 8830923 [details]
Bug 910022 - Allow websites to provide custom background colors and foreground colors for <select> popups.

https://reviewboard.mozilla.org/r/107588/#review109388

> Nit: I'm not the hugest fan of the `[, x, y, z]` pattern for dropping the first element. Not going to block on this, but I'd honestly prefer the more explicit:
> 
> `let [unused, r, g, b] = ...`
> 
> Feel free to drop though.

Adding in 'unused' causes an eslint error for 'no-unused-vars'. We can add 'unused' to the list of ignored variable names for the rule in /toolkit/.eslintrc.js, but I didn't want to do that in this patch.

> Can you avoid the escape by doing:
> 
> ```
> const pageUrl = `data:text/html,${PAGECONTENT_COLORS}`;
> ```
> 
> ?
> 
> Also, should this be PAGE_URL?

pageUrl and escape are used heavily within this test file. I didn't want to break with that. We can file a follow-up to clean up this test though, it would be a nice good-first-bug.
Comment hidden (mozreview-request)

Comment 61

2 months ago
Pushed by jwein@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/74d0d2f2b19c
Allow websites to provide custom background colors and foreground colors for <select> popups. r=mconley

Comment 62

2 months ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/74d0d2f2b19c
Status: ASSIGNED → RESOLVED
Last Resolved: 2 months ago
status-firefox54: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla54
Depends on: 1335483

Updated

2 months ago
Duplicate of this bug: 1335386
Depends on: 1336125

Updated

2 months ago
Duplicate of this bug: 1336096
Per regression bug 1315401, do we consider to uplift to Firefox 52/53 ?
Flags: needinfo?(beachjar)
(In reply to Astley Chen [:astley] (UTC+8) from comment #65)
> Per regression bug 1315401, do we consider to uplift to Firefox 52/53 ?

We're still dealing with fallout from this patch, with one fix just landed in bug 1335483 and another one up for review in bug 1336125. After those two patches have landed and stabilized we can uplift assuming no other bugs have been reported.
Flags: needinfo?(beachjar)
[Tracking Requested - why for this release]: noticeable regression for form controls that will increase as adoption of e10s increases. see comment 66 for notes about two regressions that will need to be uplifted along with this bug.
status-firefox52: --- → affected
status-firefox53: --- → affected
tracking-firefox53: --- → ?
Depends on: 1336599

Comment 68

2 months ago
Might the resolution of this issue have caused the problem reported by bug 1336301?  
In that case, items in a drop-down are only visible when the mouse cursor is on them,
all other possibilities being invisible.
(In reply to Lee McFarland from comment #68)
> Might the resolution of this issue have caused the problem reported by bug
> 1336301?  
> In that case, items in a drop-down are only visible when the mouse cursor is
> on them,
> all other possibilities being invisible.

Yes, the changes here caused that bug. Thank you for your report, I've confirmed that it isn't fixed by the other follow-up patches.
Depends on: 1336301
Duplicate of this bug: 1336430
Depends on: 1338283
Tracking since this sounds like an annoying regression in form controls.
tracking-firefox52: --- → +
tracking-firefox53: ? → +
Depends on: 1338219

Updated

a month ago
Duplicate of this bug: 1339388
Depends on: 1338850
Depends on: 1339966

Updated

a month ago
Duplicate of this bug: 1340122

Updated

a month ago
Duplicate of this bug: 1340585
If this needs to be fixed in 52, it has to be really soon now, we're building the last beta before RC today.  Or should this be deferred to 53?
Flags: needinfo?(jaws)
We now have a kill-switch (via the dom.forms.select.customstyling pref) so we could uplift it to 52 and then if an issue arises we could disable the feature by setting the pref to false for all users.

If this patch were to be uplifted, we would need to uplift this along with all of the follow-up patches to fix related regressions, which are numerous.

Uplifting to 52 would limit fix the regression for users who got on e10s earlier, and prevent it from being seen for users who still haven't been migrated to e10s. However, we would have to be monitoring feedback about broken forms and be willing to ship out a hotfix that disables the pref if necessary.

Considering all of the above, I would prefer to uplift to 53 and track there.
Flags: needinfo?(jaws)
wontfix for 52 per comment 76 and irc discussion between jaws and mconley.
status-firefox52: affected → wontfix
Depends on: 1344574

Updated

14 days ago
Depends on: 1346440

Updated

14 days ago
status-firefox-esr45: --- → unaffected
status-firefox-esr52: --- → affected

Updated

14 days ago
status-firefox-esr45: unaffected → ---
jaws, are you still intending to uplift all of this to 53?
Flags: needinfo?(jaws)
status-firefox53: affected → wontfix
Oops, just wontfixed entirely the wrong bug.
status-firefox53: wontfix → affected
I thought we were going to be OK to uplift to 53 but I just saw bug 1346440 get reported over the weekend so I think we should hold off. I do have a patch on that bug which fixes the issue though.
Flags: needinfo?(jaws)
Depends on: 1347329
Depends on: 1347089

Updated

6 days ago
Depends on: 1348617

Updated

3 days ago
Depends on: 1349460

Updated

2 days ago
Depends on: 1349647

Updated

2 days ago
Depends on: 1349701
Marking fix-optional to get this off my triage list. We can still consider uplift for this and the patch in bug 1346440, just nominate it for beta if you think it is worth the risk. The next beta build will be for beta 7 on Monday.
status-firefox53: affected → fix-optional
You need to log in before you can comment on or make changes to this bug.