1. Open this website page - https://bugzilla.mozilla.org/enter_bug.cgi?product=Core
2. Open second "Platform" dropdown menu list
3. See that visual appearance of dropdown menu list with e10s enabled is different compared to dropdown menu list with e10s disabled.
Most notable changes are that:
- font family used in foreground text isn't used in dropdown menu list
- there are too much useless space between items in dropdown menu list
Created attachment 8805192 [details]
Created attachment 8805193 [details]
Also size of the font is different.
[Tracking Requested - why for this release]: Regression
On stable builds the regression started in Firefox 48, where e10s is by default enabled.
Created attachment 8805454 [details]
Firefox 51 [e10s=enabled].png
Created attachment 8805455 [details]
Firefox 52 [e10s=enabled].png
Created attachment 8805456 [details]
Firefox 52 [e10s=disabled].png
There even was some change between Firefox 51 and Firefox 52 in this issue.
*** This bug has been marked as a duplicate of bug 1300784 ***
Bug #1300784 is only about combining e10s and non-e10s <select> dropdown mechanisms, not about regression that dropdown menu list is using wrong font family & size and have too much useless space between items.
Bug #1091592 probably regressed most of things stated in this bug.
The spacing between items was a conscious design decision.
Is it a regression that the popup uses a different font-family than the button in the page? What happened before this patch if the font-family on the page was set to Georgia, for example?
As Neil commented, the difference between e10s and non-e10s will be fixed with bug 1300784.
The e10s team triaged a number of bugs about this. Basically we switched UI elements for the drop down, and because of that, the fonts and layout changed somewhat. The consensus was that the new layout was better. Regardless, we decided we would not attempt to fix these issues since e10s is replacing non-e10s so minor font/layout differences in the dropdown are irrelevant.
What are the reasons for:
-making font smaller
-making dropdown text using other font family than on button
-increasing that much space between items, which is useless on non-touch devices
-changing appearance to be inconsistent compared to other browser?
Tracking 52- based on resolution.
Per comment #14, track 51-.
Hey Philipp, what do you think about the difference between the font being used on the button and what shows up in the popup?
You can look at https://bug1313418.bmoattachments.org/attachment.cgi?id=8805455 to see the difference. We didn't change the font on the button because we are worried about web compat.
Please, see comment #15
(In reply to Virtual_ManPL [:Virtual] - (ni? me) from comment #15)
> What are the reasons for:
> -making font smaller
> -making dropdown text using other font family than on button
> -increasing that much space between items, which is useless on non-touch
> -changing appearance to be inconsistent compared to other browser?
As I said, we switched UI elements and so the layout changed. Feel free to file bugs on individual issues.
OK, but I was hoping that we could omit bureaucracy and deal with these issues here... seems not. ;)
(In reply to Virtual_ManPL [:Virtual] - (ni? me) from comment #21)
> OK, but I was hoping that we could omit bureaucracy and deal with these
> issues here... seems not. ;)
Looks like we have newer regressions in this area due to the select styling and gpu changes, so not really the same styling issues we triaged under e10s.
(In reply to Jim Mathies [:jimm] from comment #22)
> (In reply to Virtual_ManPL [:Virtual] - (ni? me) from comment #21)
> > OK, but I was hoping that we could omit bureaucracy and deal with these
> > issues here... seems not. ;)
> Looks like we have newer regressions in this area due to the select styling
> and gpu changes, so not really the same styling issues we triaged under e10s.
I reported the GPU Process changes and regressions to select dropdown menu list (especially about these blurry and not sharp fonts in text) in bug #1315568,
but this bug wasn't about it, as it was reported before GPU Process was landed,
it's about regression from bug #1091592, which is now tracked separately as you wanted.
I am assuming bug 1300784 will fix this. Too late for 49 and 50, both are wontfix now.