1434298 - only -moz-appearance:none applied a bank site

Status: RESOLVED INACTIVE

(Web Compatibility :: Site Reports, defect, P1)

Description

[hanspr]

Attachment: Example and test case

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0
Build ID: 20180123171915

Steps to reproduce:

I enter my Bank's Website and I can not see radio buttons in it. I can not provide a link because a login is required. But after looking at their css styles applied, I noticed that they have applied this style to all radio and checkboxes

input[type="radio"] {width: auto;height: auto;-moz-appearance: none;}

I have attached a PDF file with test case to reproduce localy



Actual results:

The radio buttons are not visible


Expected results:

Radio buttons should be visible like in other browsers

Comment 1

[Gingerbread Man]

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0
20180129220114

<input type="radio" style="-moz-appearance: none;">

That's sufficient to reproduce the issue. The point of -moz-appearance: none is to remove the browser's styling from the radio button, in order to apply a custom style to it. Based on the screenshot, it doesn't look like the site is doing the latter, so the browser doesn't display anything.

Comment 2

[hanspr]

I honestly believe that some sites use this flaw -moz-appearance: none; to force users into use other browsers.

I once tried to report this to the Bank, but they ignored me completely, they say was a Firefox issue and not a design problem.

I managed to work around the problem by creating a userContent.css
With this instructions

@-moz-document domain("bank.domain.com") {
input[type="radio"] {
height:16px !important;
-moz-appearance: radio !important;
}
}

But I think this is to advanced by a normal user.

Comment 3

[hanspr]

I still think there is a bug here because if you implement the previous solution like this, it will not work because the height attribute will not reset properly by just removing the : -moz-appearance

This will not work

@-moz-document domain("bank.domain.com") {
input[type="radio"] {
-moz-appearance: radio !important;
}
}

Needs the additional

height:16px !important;

Comment 4

[Gingerbread Man]

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0
20180201100326

(In reply to hanspr from comment #3)
> Needs the additional
> 
> height:16px !important;

I see no issue when entering the following into the location bar:

data:text/html,<input type="radio" style="-moz-appearance: radio !important; height: auto !important;">

Comment 5

[hanspr]

(In reply to Gingerbread Man from comment #4)
> Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101
> Firefox/60.0
> 20180201100326
> 
> (In reply to hanspr from comment #3)
> > Needs the additional
> > 
> > height:16px !important;
> 
> I see no issue when entering the following into the location bar:
> 
> data:text/html,<input type="radio" style="-moz-appearance: radio !important;
> height: auto !important;">

Your exercise is different from my report.

My report is based on a website o file that has a defined class applied to a radio (not a style applied to a radio).

Once that page and class are loaded in the browser, it creates rules over the radio object.

If you try to remove these rules using: The Inspector or the userContent.css. Is when the wrong behavior is seen.

For some reason, removing the attributes using only the inspector does not fix the visibility problem
And if you relay on the userContent.css, you do not get to solve the issue either if you only use : -moz-appearance: radio !important; only

That is one issue that I see

The second, and must important one. Is that you should discuss with your team, that creating a class with -moz-appearance: none;. And not apply a custom styling later, removes objects from the browser.

I know that the blame is on web designers, but hope you may find a solution to it, I understand that you introduced the -moz-appearance: that creates the problem in the first place.

And because other browsers ignore it, makes it a source of problems for end users facing a bad web designer or intentioned bad design.

If you don't find anything of value on this ticket and this last post, you may close the ticket.


Thank you for your valuable time.

Comment 6

[Mats Palmgren (inactive)]

-moz-appearance:none on a radio or checkbox makes it display nothing.
This is intentional to be compatible with -webkit-appearance:none in Chrome.

The solution here is for the site to remove -moz-appearance:none,
or add -webkit-appearance:none with additional styling to make
the element render something.

I would strongly recommend not using -moz-appearance or -webkit-appearance
at all since the default rendering is pretty much always better for the user.

Comment 7

[Karl Dubost💡 :karlcow]

Attachment: radio button size

mats, 

I think there is a repaint issue for the radio element.
See the screenshot in Firefox nightly.

On top the reference test case. (working) 
   data:text/html,<input type="radio">
   The widget is 13x13 pixels (on macOS)


The second window. Here the steps to reproduce.

1. Start with 
   data:text/html,<input type="radio" style="-moz-appearance: none !important; height: auto !important;">
   OR data:text/html,<input type="radio" style="-moz-appearance: none;">
2. open the devtools
3. select input
4. Change the value of "-moz-appearance" 
   from "none !important" 
   to   "radio !important" or "radio"

The widget is 4x4 pixels.


It should be back to the default.

That might be partially the issue reported by the reporter on using his/her own CSS on top the bank site.

Comment 8

[Karl Dubost💡 :karlcow]

hanspr,

This is indeed a site issue. 

Often Web designers will use a combination of 
    "-webkit-appearance: none" 
and "-moz-appearance: none" 
AND insert an image to simulate their own widget matching their website style.

What is disturbing in this case is that they seem to have forgotten either to remove the -moz-appearance: none or to add the necessary widget rendering they were expecting.

Bank sites are usually very hard to contact. They resist to any technical input from the outside (understandable given the security issues around social engineering but still super frustrating).


They really need to remove this -moz-appearance: none.
As a real customer from this bank, you are in a better position than us to report the issue (I know you did already).
If it can help, you can point them to this discussion here and I'll be happy to support your case to them if they wish to enter in contact.

Comment 9

[Mats Palmgren (inactive)]

(In reply to Karl Dubost :karlcow from comment #7)
I don't think that's the same issue as was reported here originally,
so I doubt fixing that will fix this site.  The issue you describe
is a real bug though -- can you file a new bug report please?

Comment 10

[Karl Dubost💡 :karlcow]

Thanks Mats. I opened Bug 1435658

Comment 11

[Mike Taylor [:miketaylr]]

hanspr, would you mind giving us the URL of the bank so we can at least attempt outreach? Thanks.

(forgive me if it's in the bug already, I didn't see it)

Comment 12

[hanspr]

This is the corporate web page

http://www.scotiabank.com.mx/Default.aspx

or (in case redirects to another location, based on your location, language)

http://www.scotiabank.com.mx/es-mx/personas/default.aspx

Comment 13

[Mike Taylor [:miketaylr]]

Adam, can we try to reach out to Scotiabank? Thanks.

Comment 14

[Mike Taylor [:miketaylr]]

Hi hanspr, apologies I missed your reply, can you confirm that the issue still exists? Thanks.

Comment 15

[hanspr]

The issue still exists.

Comment 16

[Adam Stevenson [:adamopenweb]]

Reaching out to a former Mozilla employee that works there now.

Comment 17

[Ali Al Dallal [:alicoding]]

I've messaged some folks on Slack and hoping to get someone's attention from the team who's responsible for that page and will get back to you when I find out more.

Comment 18

[Firefox Bug Husbandry Bot]

See bug 1547409. Moving webcompat whiteboard tags to keywords.

Comment 20

[hanspr]

This last comment form user "rolletna", looks like spam , abuse.

Comment 21

[Karl Dubost💡 :karlcow]

Note
data:text/html,<!doctype%20html><input%20type="radio"%20style="-webkit-appearance:%20none;"> (WebKit, Blink)
and
data:text/html,<!doctype%20html><input%20type="radio"%20style="-moz-appearance:%20none;"> (Gecko)

creates the same rendering. This is (was?) a site error.
And the remedy was to contact them.