-moz-appearance button should behave like -webkit-appearance: button

RESOLVED FIXED in Firefox 59

Status

()

defect
RESOLVED FIXED
4 years ago
Last year

People

(Reporter: karlcow, Assigned: mats)

Tracking

unspecified
mozilla59
Points:
---
Dependency tree / graph
Bug Flags:
webcompat ?
in-testsuite +

Firefox Tracking Flags

(firefox59 fixed)

Details

(Whiteboard: [webkitcompat] [webcompat])

Attachments

(4 attachments, 1 obsolete attachment)

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
Whiteboard: [webkitcompat]
See Also: → 605985
Adding the screenshot in Firefox and WebKit on rendering button and background image from http://codepen.io/anon/pen/QyJMGx
Component: Layout → Layout: Form Controls
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
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
seeAlso the discussion on dev.platform
https://groups.google.com/forum/#!topic/mozilla.dev.platform/oZ9cPF8Y1pE
See Also: → 1333482
Flags: webcompat?
Whiteboard: [webkitcompat] → [webkitcompat] [webcompat]
We should fix this before implementing -webkit-appearance.
Blocks: 1368555
Assignee: nobody → lochang
Status: NEW → ASSIGNED
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.
Posted file testcae.html (obsolete) —
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?
Attachment #8926319 - Flags: feedback?(mats)
Posted file testcase.html
Attachment #8926327 - Attachment is obsolete: true
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 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)
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?
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-
This fixes the testcase for me (I haven't tested on Try yet though).

WDYT?
Attachment #8939902 - Flags: review?(lochang)
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+
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
(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+
https://hg.mozilla.org/mozilla-central/rev/36be4f8806ce
https://hg.mozilla.org/mozilla-central/rev/981938848b00
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla59
Depends on: 1445898
No longer depends on: 1445898
You need to log in before you can comment on or make changes to this bug.