1406865 - [e10s] style on <option> elements isn't respected on Linux (i.e. we need to re-enable dom.forms.select.customstyling for Linux)

Status: NEW

(Core :: Layout: Form Controls, defect, P3)

Description

[Pierre Ossman]

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20171004085519

Steps to reproduce:

Bug 910022 is marked as fixed in Firefox 54, but I'm running 56 and I'm still getting no styling whatsoever on <option> elements.

Comment 1

[Astley Chen (inactive)]

(In reply to Pierre Ossman from comment #0)
> Bug 910022 is marked as fixed in Firefox 54, but I'm running 56 and I'm
> still getting no styling whatsoever on <option> elements.

Thanks for reporting this bug.
There are still a number of bugs out there that blocked bug 1154677, which is actually a meta bug used to track overall status of <select> issues.
Could you be more specific on what styling issues you mentioned?
Thanks.

Comment 2

[Pierre Ossman]

I can't find any style that is respected. I tried this:

option {
	background: green;
	color: red;
	font-size: 0.2em;
	font-style: oblique;
	font-weight: bold;
	font-family: monospace;
}

None of the styles were applied. The only one that had any effect was font-size, which resized the <select> element, but not the text in it, nor the options entries.

Comment 3

[Pierre Ossman]

So I found this:

https://hg.mozilla.org/mozilla-central/rev/35ddc6aaed8b
https://bugzilla.mozilla.org/show_bug.cgi?id=1338283

So it seems this is somewhat intentional. The problem is that bug 1338283 has a misleading subject, which means people won't find it. Perhaps keep this bug and mark bug 1338283 as a blocker?

Comment 4

[Daniel Holbert [:dholbert]]

Yeah -- bug 1338283 was in a weird state. I've morphed it back to tracking the issue that it originally tracked (a rendering glitch which happens when custom styling is enabled), and let's use this bug here to track re-enabling custom styling.

--> Marking this as depending on on bug 1339966, because that's where the pref in question was added.  (And it's correct that this depends on bug 1338283, because we need to fix that bug's rendering issue before we can land the pref-flip.)

Comment 5

[Vasilis Lourdas]

Hi,

What is the status with this bug? It's pretty awful to see totally unstyled option elements in select lists in Linux. In Windows, at least, you can style the color, but not the size or border... This is really bad and it's a side effect from the e10s, before that it worked perfectly. Is there a plan to get this fixed in the near future?

Comment 6

[Daniel Holbert [:dholbert]]

At a minimum, we need to sort out the issues described in bug 1338283 before we can reenable this pref. (I just posted there to see what the status is, but I'm guessing it's not a top priority at the moment.)

Comment 9

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #6)

At a minimum, we need to sort out the issues described in bug 1338283 before
we can reenable this pref. (I just posted there to see what the status is,
but I'm guessing it's not a top priority at the moment.)

It looks like bug 1338283 has gone away. Emilio, do you think we can land this pref-flip now?

Comment 10

[Emilio Cobos Álvarez [:emilio]]

From running with it enabled for a while in the past, one thing that's very noticeable is the padding in the menuitems being too small.

It goes from depending on the gtk theme to be 1px 5px, and that's too little IMO (at least compared with the usual GTK themes). So I think at least that bit (in menu.css) needs tweaking before enabling by default (probably at least making it match Adwaita?)...

With that I think that'd be ok, though maybe we could check with UX or so? But given we support it on macOS and Windows yeah, it seems not very objectionable.

Comment 11

[Daniel Holbert [:dholbert]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #10)

From running with it enabled for a while in the past, one thing that's very noticeable is the padding in the menuitems being too small.

Thanks. I've filed bug 1751644 for what I think (?) is that issue.

Comment 12

[Dão Gottwald [:dao]]

Daniel and Emilio, do you think we're at a point where we can re-enable this? Are there outstanding issues we know about that should be added to the dependency list here?

Comment 13

[Emilio Cobos Álvarez [:emilio]]

I don't think there are outstanding issues, but on the other hand, we disabled it on macOS. A couple subtests in browser_selectpopup.js fail on Linux (locally, at least), need to debug why too, but I haven't had the time.

Comment 14

[Daniel Holbert [:dholbert]]

I think we could try to enable this (once we've addressed, or annotated [if we must] the test-failures that Emilio noted). I've been running Linux Nightly with the pref enabled for months, and haven't noticed any issues, FWIW.

Comment 15

[importu]

There's also a weird menu padding problem with Linux select elements, that doesn't exist in Windows:
Bug 1783498

The people who use transparent background for select elements (for example, to make a site background image visible behind the select) would get a white padding above and below select options in the menu (Example 1 in the bug).

And if they also use a hover background color and a background transition on the select element, the padding background color would switch between white and the hover background color when the mouse cursor leaves or enters the menu/select boundaries (Example 2 in the bug).

Comment 16

[Daniel Holbert [:dholbert]]

(In reply to importu from comment #15)

There's also a weird menu padding problem with Linux select elements, that doesn't exist in Windows:

I see that same issue in firefox on Windows 10, FWIW; see my screenshot/screencast in bug Bug 1783498 comment 6 - 7. We can discuss/diagnose more on that bug (maybe there's some nuance that I'm missing, or maybe certain Windows configurations are affected vs. unaffected, or maybe the testcase needs something more in order to demonstrate the Windows/Linux difference?)

But at this point, it's not obvious that there's any Linux-specific badness there.

Comment 17

[Pierre Ossman]

Something has regressed here. The setting dom.forms.select.customstyling no longer has any effect. :/

Was this intentional?

Comment 18

[Daniel Holbert [:dholbert]]

(In reply to Pierre Ossman from comment #17)

Something has regressed here. The setting dom.forms.select.customstyling no longer has any effect. :/

Hmm, it works as-expected on my end. If I toggle that pref in Firefox Nightly, then e.g. the dropdown-menu on https://bug1783498.bmoattachments.org/attachment.cgi?id=9290740 renders with a blue background behind every menu-option. I tested on Wayland and non-Wayland, using Ubuntu 22.04.

Maybe file a bug on whatever you're seeing, with more details about your configuration/distro and the testcase you're using? (RE changes-that-might-be-involved-here: we landed bug 1828413 in April 2023, which did change the look if that testcase a little bit for me, but the custom colors are still there.)

Comment 19

[Pierre Ossman]

Never mind, bad testing on my part. Sorry for the noise.

I am seeing a detail I haven't noticed before, and I'm uncertain if it is covered by existing bugs?

Styles applied by the selector option:checked do not work. option[selected=selected] does, though. Inspector thinks both match, but the rendering is only affected by the latter. Chrome does not have this issue.

Comment 20

[Daniel Holbert [:dholbert]]

No worries. I spun off bug 1856725 for the option:checked thing; I see that too.

Comment 22

[James Cobban]

How do I get a fix for this bug? Bear in mind that I do not have control of what browsers or operating systems my customers use. I need to be able to code web pages that work the same in both Chrome and Firefox. The following URL works on Chrome, and I am told it also works on Firefox on MSWindows

https://www.jamescobban.net/FamilyTree/testselect.html

How is it possible that Mozilla has known about this problem for seven years and has chosen to do nothing, without a clear published justification which your staff can point to. On the page:

https://www.mozilla.org/en-US/contact/

I do not see any option for complaining about Mozilla itself. What is the point of closing a problem as a duplicate of another problem if ther other problem is not resolved. I NEED A RESOLUTION.

The current status is:

Status:
NEW
Tracking Flags:
Tracking Status
firefox57 --- wontfix
firefox58 --- affected
Assignee: Unassigned
Reporter: ossman
Triage Owner: emilio
CC:

After being basically told by the participants in this forum to FO, particularly by Emilio, the TRIAGE officer, I now want Steve Teixeira or Carlos Torres or Laura Chambers to add an explanation to this bug report explaining EXACTLY why they have refused to seven years to assign anyone to fix this issue! I can understand declaring wontfix on an obsolete release, but I am on Release 125 and you still haven't fixed this! All you did when I raised it again was point me at this empty problem. As far as I can tell until Emilio found this ANCIENT problem and used it to close my new complaint, NOBODY HAD EVEN LOOKED AT THIS ISSUE IN SEVEN YEARS!

Please explain why I should not be pissed off that you have left this problem open for seven years?

Comment 23

[Daniel Holbert [:dholbert]]

James, continued comments like comment 22 won't be tolerated; please read https://bugzilla.mozilla.org/page.cgi?id=etiquette.html , particularly "No abusing people.", and especially this second part:

2. No obligation. "Open Source" is not the same as "the developers must do my bidding." Everyone here wants to help, but no one else has any obligation to fix the bugs you want fixed. Therefore, you should not act as if you expect someone to fix a bug by a particular date or release. Aggressive or repeated demands will not be received well and will almost certainly diminish the impact of and interest in your suggestions.

Keep in mind, Firefox is a product offered to users for free, developed by a relatively small team, juggling many bugs and many features across many platforms. Some bugs are higher priority than others; some bugs are more complex than others (even if they may not look like it on the surface). This does mean that some bugs sit open for many years.

Bear in mind that I do not have control of what browsers or operating systems my customers use.

That's true. You might be alarmed to learn that Safari every browser on macOS (Chrome/Safari/Firefox), every browser on iOS / iPadOS, Chromium-on-Android (along with Firefox on Android) all render your menu-dropdown with a plain unstyled background, just like Firefox-on-Linux does.

What is the point of closing a problem as a duplicate of another problem if ther other problem is not resolved.

This is standard practice for our bug tracking system (and many others). It's not meant as an affront to the duplicated bug; it's simply so that we don't end up with many different bug reports with different people repeating work in different places.

NOBODY HAD EVEN LOOKED AT THIS ISSUE IN SEVEN YEARS!

That's not at all true; it's made slow progress over the years, and has been looked at. The most recent three comments are from 7 months ago; and each of the 6 "Depends-on" bugs (which have been fixed) were each stepping stones towards getting this fixed.

Anyway: this was a courtesy response; further engagement along the lines of comment 22 are unacceptable and unwelcome.