Closed
Bug 1246836
Opened 9 years ago
Closed 7 years ago
-moz-appearance button should behave like -webkit-appearance: button
Categories
(Core :: Layout: Form Controls, defect)
Core
Layout: Form Controls
Tracking
()
RESOLVED
FIXED
mozilla59
Tracking | Status | |
---|---|---|
firefox59 | --- | fixed |
People
(Reporter: karlcow, Assigned: MatsPalmgren_bugz)
References
Details
(Whiteboard: [webkitcompat] [webcompat])
Attachments
(4 files, 1 obsolete file)
We have a difference of behavior with regards to WebKit and Blink when setting the appearance to a button.
I created an example at http://codepen.io/anon/pen/QyJMGx
The screenshot in Firefox and Safari are visible at https://github.com/webcompat/web-bugs/issues/1006#issuecomment-181660121
In a scenario such as:
.webkitimg {
-webkit-appearance: button;
background: url(data:image/png;base64,…) no-repeat scroll 100% 50% transparent !important;
background-size: 7px 9px !important;
}
WebKit, Blink drops the button to show only the image.
Gecko keeps both which creates a repetition of widget controls.
Left a comment on the compat spec too.
https://github.com/whatwg/compat/issues/6
Reporter | ||
Updated•9 years ago
|
Whiteboard: [webkitcompat]
Reporter | ||
Comment 1•9 years ago
|
||
Adding the screenshot in Firefox and WebKit on rendering button and background image from http://codepen.io/anon/pen/QyJMGx
Updated•9 years ago
|
Component: Layout → Layout: Form Controls
Reporter | ||
Comment 2•9 years ago
|
||
See also https://webcompat.com/issues/1005
See Also: → https://webcompat.com/issues/1005
Reporter | ||
Comment 3•8 years ago
|
||
ok let me be clearer.
http://www.la-grange.net/2017/02/21/appearance/appearance-test-0001.html
Summary: Drops moz-appearance button when a background-image is set → -moz-appearance button should behave like -webkit-appearance: button
Reporter | ||
Comment 4•8 years ago
|
||
I created a test.
http://www.la-grange.net/2017/02/21/appearance/appearance-test-0001.html
The issue is that when we set
-moz-appearance: button
we get a widget with arrows while -webkit-appearance: button deliver a simple button.
So if the site does:
-webkit-appearance: button;
-moz-appearance: button;
background: <image>
The rendering looks broken in Firefox.
and if the site does:
-webkit-appearance: button;
-moz-appearance: none;
appearance: button
background: <image>
the site will be broken if we unship -moz-appearance: none
Reporter | ||
Comment 5•8 years ago
|
||
seeAlso the discussion on dev.platform
https://groups.google.com/forum/#!topic/mozilla.dev.platform/oZ9cPF8Y1pE
See Also: → 1333482
Reporter | ||
Updated•8 years ago
|
Flags: webcompat?
Whiteboard: [webkitcompat] → [webkitcompat] [webcompat]
Assignee | ||
Comment 6•7 years ago
|
||
We should fix this before implementing -webkit-appearance.
Blocks: 1368555
Updated•7 years ago
|
Assignee: nobody → lochang
Updated•7 years ago
|
Status: NEW → ASSIGNED
Comment 7•7 years ago
|
||
I think here is the place http://searchfox.org/mozilla-central/source/widget/nsNativeTheme.cpp#345-354 where causes us not painting the button with theme when background is set. But I am still figuring out how to fix it in a reasonable way.
Comment hidden (mozreview-request) |
Comment 9•7 years ago
|
||
Comment 10•7 years ago
|
||
mozreview-review |
Comment on attachment 8926319 [details]
Bug 1246836 - Fallback to render customized button when -moz-appearance is button with border or background is set.
https://reviewboard.mozilla.org/r/197604/#review202846
Hi mats,
Could you give some feedback on the patch? Thanks.
I tried to make nsComboBoxControlFrame add both nsDisplayThemedBackground and nsDisplayBackgroundImage to DisplayList so it can paint out both button with native theme and the background image.
::: widget/nsNativeTheme.cpp:351
(Diff revision 1)
> + if (aFrame->Type() == LayoutFrameType::ComboboxControl)
> + return false;
> + }
> +
> return (aWidgetType == NS_THEME_NUMBER_INPUT ||
> aWidgetType == NS_THEME_BUTTON ||
It seems contradict to me here. Currently, we allow author to style button and not paint out the button with native theme when border or background is set. But now we expect to paint out both button and border or background.
Do you have any thought or how we could fix this in other way?
Updated•7 years ago
|
Attachment #8926319 -
Flags: feedback?(mats)
Updated•7 years ago
|
See Also: → https://webcompat.com/issues/13245
Comment 11•7 years ago
|
||
Attachment #8926327 -
Attachment is obsolete: true
Comment 12•7 years ago
|
||
Comment on attachment 8926319 [details]
Bug 1246836 - Fallback to render customized button when -moz-appearance is button with border or background is set.
It seems we should fix at the custom drawing instead of the theme part.
Attachment #8926319 -
Flags: feedback?(mats)
Comment hidden (mozreview-request) |
Comment 14•7 years ago
|
||
Comment on attachment 8926319 [details]
Bug 1246836 - Fallback to render customized button when -moz-appearance is button with border or background is set.
Hi mats,
Could you feedback on the patch? Thanks.
So here is proposal of fixing the button issue by adding a anonymous appearance content and a text content into nsComboboxFrame. We dynamic allocate the appearance content based on the appearance value. And render it when there is no theme but appearance is changed. And the selection will be updated to the text content.
The patch is able to successfully fallback render the customized button when appearance is button and border or background is set. Though, there are still some trivial problems need to solved such as the rendering of customized button (will render a down arrow) and could not render the background image since it is cover by appearance content.
Attachment #8926319 -
Flags: feedback?(mats)
Comment 15•7 years ago
|
||
Note:
So this solution could only fix the select element with appearance button for addressing the most common webcompat issue...
If this work, maybe we could further add an anonymous content to every frame?
Assignee | ||
Comment 16•7 years ago
|
||
Comment on attachment 8926319 [details]
Bug 1246836 - Fallback to render customized button when -moz-appearance is button with border or background is set.
This solution seems a bit too complex to solve the problem at hand.
We already have code to suppress the dropdown button for
-moz-appearance:none (added in bug 649849). I think we could
generalize that by inverting the condition in that code so that it
tests -moz-appearance != menulist instead (assuming this is what
Chrome does).
Attachment #8926319 -
Flags: feedback?(mats) → feedback-
Assignee | ||
Comment 17•7 years ago
|
||
This fixes the testcase for me (I haven't tested on Try yet though).
WDYT?
Attachment #8939902 -
Flags: review?(lochang)
Comment 18•7 years ago
|
||
Comment on attachment 8939902 [details] [diff] [review]
Render the dropdown button for -moz-appearance:menulist only.
Review of attachment 8939902 [details] [diff] [review]:
-----------------------------------------------------------------
The solution looks good to me. However, I was thinking about whether there is a general solution to fix the appearance issue, which we can't fallback using customized drawing when an appearance value is set and also styled with border or background. But this might be a more complex and big topic. Or maybe we can fix the issue case by case based on the use cases like the solution you provided?
Attachment #8939902 -
Flags: review?(lochang) → review+
Comment 19•7 years ago
|
||
Pushed by mpalmgren@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/36be4f8806ce
part 1 - Render the <select> dropdown button for -moz-appearance:menulist only. r=louis
https://hg.mozilla.org/integration/mozilla-inbound/rev/981938848b00
part 2 - Reftest. r=me
Assignee | ||
Comment 20•7 years ago
|
||
(In reply to Louis Chang [:louis] from comment #18)
> However, I was thinking about whether there
> is a general solution to fix the appearance issue, which we can't fallback
> using customized drawing when an appearance value is set and also styled
> with border or background. But this might be a more complex and big topic.
Yeah, I think we should try to make small incremental changes for now.
Our time is better spent on fixing the blockers for bug 1368555 quickly
so that we can enable -webkit-appearance soon.
Assignee: lochang → mats
Flags: in-testsuite+
Comment 21•7 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/36be4f8806ce
https://hg.mozilla.org/mozilla-central/rev/981938848b00
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
status-firefox59:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla59
You need to log in
before you can comment on or make changes to this bug.
Description
•