Open Bug 1406865 Opened 7 years ago Updated 2 years ago

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

Categories

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

56 Branch
defect

Tracking

()

Tracking Status
firefox57 --- wontfix
firefox58 --- affected

People

(Reporter: ossman, Unassigned)

References

(Blocks 1 open bug)

Details

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.
Component: Untriaged → CSS Parsing and Computation
Product: Firefox → Core
Component: CSS Parsing and Computation → Layout: Form Controls
Depends on: 910022
(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.
Flags: needinfo?(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.
Flags: needinfo?(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?
Status: UNCONFIRMED → NEW
Depends on: 1338283
Ever confirmed: true
Priority: -- → P3
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.)
Depends on: 1339966
Summary: [e10s] style on <option> elements isn't respected → [e10s] style on <option> elements isn't respected on Linux (i.e. we need to re-enable dom.forms.select.customstyling for Linux)
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?
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.)

(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?

Flags: needinfo?(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.

Flags: needinfo?(emilio)
Depends on: 1751545
Depends on: 1751644

(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.

Depends on: 1785155

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?

Flags: needinfo?(emilio)
Flags: needinfo?(dholbert)

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.

Flags: needinfo?(emilio)

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.

Flags: needinfo?(dholbert)

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).

Flags: needinfo?(emilio)
Flags: needinfo?(dholbert)
Flags: needinfo?(dao+bmo)

(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.

Flags: needinfo?(emilio)
Flags: needinfo?(dholbert)
Flags: needinfo?(dao+bmo)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.