[e10s] Properly style <option> elements in the parent process UI (support CSS on Select Options)

VERIFIED FIXED in Firefox 67

Status

()

defect
P2
normal
VERIFIED FIXED
2 years ago
2 months ago

People

(Reporter: msuboh, Assigned: emilio)

Tracking

(Blocks 4 bugs)

54 Branch
mozilla67
Points:
---
Dependency tree / graph
Bug Flags:
webcompat +

Firefox Tracking Flags

(firefox-esr60 wontfix, firefox57 wontfix, firefox58 wontfix, firefox59 wontfix, firefox60 wontfix, firefox61 wontfix, firefox65 wontfix, firefox66 wontfix, firefox67 verified, firefox68 verified)

Details

Attachments

(2 attachments)

Reporter

Description

2 years ago
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.109 Safari/537.36

Steps to reproduce:

Try Fiddle here with Multi-Process Enabled
https://stackoverflow.com/questions/41244238/firefox-dropdown-option-font-size-not-being-rendered


Actual results:

html option tag is not styled 


Expected results:

CSS style for html option like font, color ... etc
Component: Untriaged → Layout: Form Controls
Product: Firefox → Core
Priority: -- → P3

Comment 1

2 years ago
If this bug is going to be de-prioritized, Firefox should be updated in the interim to, at a bare minimum, restore the historical behavior of rendering the select options in the same font and size as the parent select control. Since every other major browser (including Firefox pre-e10s) maintains consistency between the select control and its child options unless otherwise specified, the current e10s behavior of rendering options with an arbitrary default font and size makes the controls look incredibly awkward or outright broken to end users.
Reporter

Updated

2 years ago
Severity: normal → major
Priority: P3 → P1

Updated

2 years ago
Blocks: e10s-select
Severity: major → normal
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: webcompat+
OS: Unspecified → All
Priority: P1 → P2
Hardware: Unspecified → All
Blocks: e10s-select-styling
No longer blocks: e10s-select

Updated

2 years ago
Blocks: 1402627

Updated

Last year
Duplicate of this bug: 1431757

Comment 4

Last year
Please fix or at least default to a monospaced font

Comment 6

Last year
If i good understand, this bug was here with version 54, after it was resolved in the version 56, and now it is back here!?
I did the manipulation that Cristna Badescu told me, thank you very much!
i type "about:config" in the adress bar, turn "browser.tabs.remote.autostart" pref to "false", and all work good, if i want i can change only an option style change with <OPTION VALUE=1 style="font-size:8px;">text</option> for example!
So that must be very easy too put this option "browser.tabs.remote.autostart" pref to "false" by default!! I hope in the next official version 60 that will be OK!!
(In reply to edecorvet from comment #6)
> If i good understand, this bug was here with version 54, after it was
> resolved in the version 56, and now it is back here!?
> I did the manipulation that Cristna Badescu told me, thank you very much!
> i type "about:config" in the adress bar, turn
> "browser.tabs.remote.autostart" pref to "false", and all work good, if i
> want i can change only an option style change with <OPTION VALUE=1
> style="font-size:8px;">text</option> for example!
> So that must be very easy too put this option
> "browser.tabs.remote.autostart" pref to "false" by default!! I hope in the
> next official version 60 that will be OK!!

It's not quite as easy. browser.tabs.remote.autostart = false basically disables multi-process Firefox, which you probably don't want to do.

This bug is effectively blocked in rendering <select> in the content process, which is bug 1421229.
Depends on: content-select

Comment 8

Last year
Thank you for all the precisions, i hope you'll find a good solution!

Updated

4 months ago
Duplicate of this bug: 1528688

Comment 10

4 months ago

This bug really bothers me. Look at how bad the non-bold text is on Firefox. http://i.picpar.com/FYgd.png But on Chromium it looks fine. Really upsetting that you can't style options.

Assignee

Comment 11

4 months ago

I'd like to know which are the styles that people expect to apply to <option>. Right now we pass down color, background-color, and text-shadow. It makes sense to also support other font styles IMHO.

The colors are passed around to the parent process here:

https://searchfox.org/mozilla-central/rev/ee40541496d3ad738097eebadaf4965ca1343b7a/toolkit/actors/SelectChild.jsm#117

So it should not be too bad to support other properties I think? Mike, would you be open to add some other properties to those? Or is there another plan to style the dropdown?

Flags: needinfo?(mconley)

Comment 12

4 months ago

I really want font-weight. It's so strange to see a thin fonts drop down after clicking on a bold select menu.

Comment 13

4 months ago

From my perspective, the highest priority would be passing down font-size (in a similar vein to epykest's note about the weight). Having a select control with a large base font and comparatively tiny options (or vice versa, small font with comparatively large options) looks awkward and can make the control less user-friendly. The sample in the StackOverflow post referenced by the original reporter is a good example of how odd the controls can look in Firefox vs other browsers.

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

So it should not be too bad to support other properties I think? Mike, would you be open to add some other properties to those? Or is there another plan to style the dropdown?

The question of what properties to support might be best answered by abovens, but at the very least I think we should have parity with the other browsers for consistency. Do we know what styles they support?

Flags: needinfo?(mconley)
Assignee

Comment 15

4 months ago

And cleanup / make the code a bit more generic while at it.

Assignee

Comment 16

4 months ago

Comment on attachment 9045201 [details]
Bug 1375476 - Support font-style / font-weight and font-size on <option> elements.

WDYT of this Mike?

Attachment #9045201 - Flags: feedback?(mconley)
Assignee

Updated

4 months ago
Assignee: nobody → emilio
Assignee

Comment 17

4 months ago

Comment on attachment 9045201 [details]
Bug 1375476 - Support font-style / font-weight and font-size on <option> elements.

May as well get a proper review.

Attachment #9045201 - Flags: feedback?(mconley)
Assignee

Updated

4 months ago
Duplicate of this bug: 1530163

Hey emilio, I just wanted to let you know that I've seen this, and that I should have some feedback for you tomorrow (Monday).

Assignee

Comment 20

4 months ago

(In reply to Mike Conley (:mconley) (:⚙️) from comment #19)

Hey emilio, I just wanted to let you know that I've seen this, and that I should have some feedback for you tomorrow (Monday).

No worries, thanks! This is not terribly urgent, I guess, given how long has it been opened for :)

Assignee

Updated

4 months ago
Blocks: 1530709

Comment 21

4 months ago
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/1d1443507be4
Support font-style / font-weight and font-size on <option> elements. r=mconley

Comment 22

4 months ago
bugherder
Status: NEW → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla67
Duplicate of this bug: 1409638
Duplicate of this bug: 1424624
See Also: → 1536148
Assignee

Updated

3 months ago
Depends on: 1536264
Assignee

Updated

3 months ago
Duplicate of this bug: 1350258
Flags: qe-verify+

Updated

2 months ago
Depends on: 1542193
Regressions: 1542193

I managed to reproduce the issue using an older build of Nightly from 2017-04-22 on Windows 10 x64.
I retested everything on latest Nightly 68.0a1 and beta 67.0b15 using Windows 10 x64, Ubuntu 16.04 x64 and macOS 10.14. The bug is not reproducing anymore.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.