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

RESOLVED FIXED in Firefox 59

Status

()

RESOLVED FIXED
3 years ago
6 months ago

People

(Reporter: karlcow, Assigned: mats)

Tracking

(Blocks: 1 bug)

unspecified
mozilla59
Points:
---
Bug Flags:
webcompat ?
in-testsuite +

Firefox Tracking Flags

(firefox59 fixed)

Details

(Whiteboard: [webkitcompat] [webcompat])

Attachments

(4 attachments, 1 obsolete attachment)

(Reporter)

Description

3 years ago
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

3 years ago
Whiteboard: [webkitcompat]
(Reporter)

Updated

3 years ago
See Also: → bug 605985
(Reporter)

Comment 1

3 years ago
Created attachment 8717263 [details]
firefox-webkit-button.png

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
(Reporter)

Comment 3

2 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

2 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

2 years ago
seeAlso the discussion on dev.platform
https://groups.google.com/forum/#!topic/mozilla.dev.platform/oZ9cPF8Y1pE
See Also: → bug 1333482
(Reporter)

Updated

2 years ago
Flags: webcompat?
Whiteboard: [webkitcompat] → [webkitcompat] [webcompat]
(Assignee)

Comment 6

11 months ago
We should fix this before implementing -webkit-appearance.
Blocks: 1368555

Updated

11 months ago
Assignee: nobody → lochang

Updated

11 months ago
Status: NEW → ASSIGNED

Comment 7

11 months 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

11 months ago
Created attachment 8926327 [details]
testcae.html

Comment 10

11 months 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

11 months ago
Attachment #8926319 - Flags: feedback?(mats)

Comment 11

11 months ago
Created attachment 8926738 [details]
testcase.html
Attachment #8926327 - Attachment is obsolete: true

Comment 12

10 months 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

9 months 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

9 months 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

9 months 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

9 months ago
Created attachment 8939902 [details] [diff] [review]
Render the dropdown button for -moz-appearance:menulist only.

This fixes the testcase for me (I haven't tested on Try yet though).

WDYT?
Attachment #8939902 - Flags: review?(lochang)

Comment 18

9 months 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

9 months 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

9 months 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

9 months ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/36be4f8806ce
https://hg.mozilla.org/mozilla-central/rev/981938848b00
Status: ASSIGNED → RESOLVED
Last Resolved: 9 months ago
status-firefox59: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla59

Updated

6 months ago
Depends on: 1445898
(Assignee)

Updated

6 months ago
No longer depends on: 1445898
You need to log in before you can comment on or make changes to this bug.