Closed Bug 978949 Opened 12 years ago Closed 3 years ago

Drop-down arrow of <select style="border:1px solid black"> does not zoom well on Linux, due to using a cross-platform button for dropdown arrow (whose borders expand when we zoom, despite no extra width becoming available)

Categories

(Core :: Widget: Gtk, defect, P4)

Product:
Core
Component:
Widget: Gtk
Platform:
All
Linux
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: alexhenrie24, Unassigned)

References

Details

Attachments

(4 files)

Lubuntu 13.10 screenshot
3.00 KB, image/png
Details
Windows 7 screenshot
1.36 KB, image/png
Details
strawman patch (using toolbarbutton-dropdown)
899 bytes, patch
Details | Diff | Splinter Review
Proposed patch
5.70 KB, patch
dholbert
: feedback+
Details | Diff | Splinter Review
Open the following and zoom in: data:text/html,%3Cselect%20style=%22border:1px%20solid%20black%22%3E%3Coption%3EFoobar%3C/option%3E%3C/select%3E Note that when you zoom in, the drop-down arrow becomes distorted and pixellated. This does not appear to be a problem on Windows 7. I'm on Lubuntu 13.10. I really don't care about the drop-down arrow not being perfectly matched to the system theme, but I would like it to look nice when zooming in.
Attached image Windows 7 screenshot —
I tracked the problem down to nsButtonFrameRenderer.cpp, so this bug is probably not limited to GTK, but I still don't know how to fix it. To clarify: the border around the drop-down button should remain 2 display pixels wide no matter what the zoom level is.
Component: Widget: Gtk → Layout: Form Controls
A few facts: (1) On Windows, it looks like we're drawing the dropdown-button with *native* button theming, whereas on Linux/GTK, we're drawing it with our cross-platform fallback theming. We can keep a native button on Windows because the button is logically separate; we can render the author's desired border on the outer control, while still rendering the inner button the same way. But we can't do that on Linux/GTK because the GTK <select> control renders as one big button (with arrows overlaid onto it). So when the author adjusts the border, we have to ditch the GTK look-and-feel entirely. (2) The entire arrow-button area stays the exact same on-screen width as I zoom in, on Linux. (but the button-borders get larger, as noted above, leaving no space for the contents) The fixed-width is clearer in a testcase where it's right-aligned: data:text/html,<body style="margin: 0"><select style="background: yellow; border:1px solid black; float:right"><option>Foobar</option></select> This is presumably due to some nsComboboxControlFrame sizing logic that keeps the downarrow the same size while we zoom in. SO: given the above, I see a few approaches to fixing this. (a) Make cross-platform buttons react to full-page-zoom by not changing their on-screen border-widths (as suggested in comment 3). This is probably non-trivial and might have undesirable side effects on buttons in other contexts. (b) Give GTK <select> an "intermediate" look-and-feel, where it's not the "true" native single-giant-button look, but instead a textarea plus a *native* dropdown button (rather than a cross-platform button). Then, I expect this *native* dropdown button's borders won't expand as we zoom, and we'll look approximately like Windows. (c) Make the dropdown button area increase its width as we zoom in a <select>, *if* the select is using a cross-platform button internally. (So the button's borders will grow as they do now, but the space it has available to it will grow too, so we'll be fine.) In other words, change Fact (2) above. (c) is probably the easiest option here. (b) is also probably doable but might look weird. And I think we probably shouldn't do (a), since it would break other content. (I just listed it for completeness)
Summary: Drop-down arrow of <select style="border:1px solid black"> does not zoom well on Linux → Drop-down arrow of <select style="border:1px solid black"> does not zoom well on Linux, due to using a cross-platform button for dropdown arrow (whose borders expand when we zoom, despite no extra width becoming available)
FWIW: the styling for the button inside of a select is here: http://mxr.mozilla.org/mozilla-central/source/layout/style/forms.css?rev=6fb8bc793891#240 and the reason for the Windows vs. GTK difference on this bug's testcase is this line: > 248 -moz-appearance: menulist-button; That has no effect on <buttons> on GTK (since, as noted above, GTK doesn't have a separate dropdown-button in its <select> controls), but on Windows, it makes us paint the entire border-box area to look like a native dropdown button. Testcase to demonstrate this difference (renders as a pink cross-platform button on Linux, renders as a native non-pink dropdown button on Windows): data:text/html,<button style="width: 100px; height: 100px; background: pink; -moz-appearance: menulist-button"> So one way to achieve (b) would be to change the "-moz-appearance: menulist-button;" code in nsNativeThemeGTK.cpp -- that is, the NS_THEME_DROPDOWN_BUTTON special-casing -- to do something else. We could perhaps make it render like "moz-appearance: toolbarbutton-dropdown" (NS_THEME_TOOLBAR_BUTTON_DROPDOWN), which seems to be how we render downarrow in the searchbar and perhaps the URLbar on Linux...
Here's a strawman patch, making us use toolbarbutton-dropdown in forms.css. This makes us render something closer to the URLbar / searchbar on linux (just a downarrow, no special button bordering), and it zooms nicely. This is "strawman" because we probably don't want to change this in forms.css - we want to change what menulist-button actually renders like on linux, as noted in previous comment. Alex, would you be interested in digging deeper here?
Priority: -- → P4
Attached patch Proposed patch — — Splinter Review
Switching to MOZ_GTK_TOOLBARBUTTON_ARROW looks much better. The one issue I found is that to support low zoom levels I had to lower the minimum size of NS_THEME_DROPDOWN_BUTTON to match NS_THEME_BUTTON. I commented out moz_gtk_get_combo_box_entry_button_size because it is no longer needed with this approach. https://tbpl.mozilla.org/?tree=Try&rev=f93d14f4bb2f Daniel, if you'd like to keep working on this you're welcome to. I really don't have time to be doing more Mozilla stuff right now.
Attachment #8389475 - Flags: feedback?(dholbert)
Comment on attachment 8389475 [details] [diff] [review] Proposed patch I don't really know the widget code well enough to be sure if this is right, but it generally seems reasonable to me. (Unfortunately I don't have cycles to work on this at the moment, either.)
Attachment #8389475 - Flags: feedback?(dholbert) → feedback+
(Moving this bug back to Widget:GTK, since it seems like that's where the fix for this will likely need to happen. The nsButtonFrameRenderer class mentioned in comment 3 is only involved to the extent that it's reacting to the primitives that Widget:GTK provides it with (or does not provide it with, in this case).) (karl or roc or someone else familiar with GTK widget code should probably eventually be the person to sign off on a strategy & patch here.)
Component: Layout: Form Controls → Widget: Gtk
(Note: the Try run from comment 7 has some reftest failures - those appear to be entirely due to the dropdown arrow being light gray in the testcase vs dark gray in the reference, for some reason.)
Daniel, Not sure if it's the same issue as this one or if we should open a new bug for https://webcompat.com/issues/15841
Flags: needinfo?(dholbert)
That looks like a version of this same issue, yeah.
Flags: needinfo?(dholbert)
See Also: → https://webcompat.com/issues/15841
Webcompat Priority: --- → ?

Tom, is this even still an issue?

Webcompat Priority: ? → P3
Flags: needinfo?(twisniewski)

I think this was fixed by our "non-native theme" (if not earlier than that).

Testing on current Linux Nightly, the downarrow button zooms just fine now for the data URI in comment 0, and the downarrows look fine on https://soundcloud.com/settings/content as well. (They're not tiny/smooshed as they were in the screenshots on https://webcompat.com/issues/15841 )

Status: NEW → RESOLVED
Closed: 3 years ago
Flags: needinfo?(twisniewski)
Resolution: --- → WORKSFORME
Webcompat Priority: P3 → ---
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: