[e10s] Properly style <option> elements in the parent process UI (support CSS on Select Options)
Categories
(Core :: Layout: Form Controls, defect, P2)
Tracking
()
People
(Reporter: msuboh, Assigned: emilio)
References
(Blocks 2 open bugs, Regressed 2 open bugs)
Details
Attachments
(2 files)
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
Updated•4 years ago
|
Updated•3 years ago
|
Updated•3 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.
Updated•3 years ago
|
Updated•3 years ago
|
Comment 2•3 years ago
|
||
https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Move_fix-optionals
Updated•3 years ago
|
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!!
Assignee | ||
Comment 7•3 years ago
|
||
(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.
Thank you for all the precisions, i hope you'll find a good solution!
Comment 10•2 years 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•2 years 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:
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?
Comment 12•2 years 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•2 years 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?
Assignee | ||
Comment 15•2 years ago
|
||
And cleanup / make the code a bit more generic while at it.
Assignee | ||
Comment 16•2 years ago
|
||
Comment on attachment 9045201 [details]
Bug 1375476 - Support font-style / font-weight and font-size on <option> elements.
WDYT of this Mike?
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 17•2 years 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.
Updated•2 years ago
|
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•2 years 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 :)
Comment 21•2 years 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•2 years ago
|
||
bugherder |
Comment 23•2 years ago
|
||
I guess this can ride the trains.
Updated•2 years ago
|
Comment 27•2 years ago
|
||
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.
Description
•