Input renders black box on inputs when background is set to transparent in High Contrast Mode
Categories
(Core :: Widget: Win32, defect, P3)
Tracking
()
People
(Reporter: adrian, Unassigned)
References
(Depends on 1 open bug)
Details
(Keywords: regression)
Attachments
(1 file)
806.90 KB,
image/gif
|
Details |
When setting an input to have a background color of transparent !important;
Firefox renders a border & solid black background in High Contrast Mode, however it doesn't appear to happen when using background-color: transparent
.
The following two links show snapshots comparing other browsers in high contrast mode where this occurs:
background:transparent !important
- https://github.com/06b/High-Contrast-Mode-Reduced-Test-Cases/tree/master/02-transparent%20!importantbackground-color:transparent !important
- https://github.com/06b/High-Contrast-Mode-Reduced-Test-Cases/tree/master/16-transparent%20!important
With current web design trends shifting to material design-ish styles / floating labels, this becomes an issue for those using Windows High Contrast Mode because it can overlap the label.
This test case is an example of a material design filled text field which the issue occurs.
This doesn't occur on browsers based on the legacy Gecko engine. Tested with Firefox ESR 52.9.2 as that was the last Firefox ESR that was based on the legacy Gecko, also tested with SeaMonkey 2.49.4, Waterfox 56.2.8, Pale Moon 28.4.0. So I think is this a regression which was introduced with Firefox Quantum and it appears to also occur Firefox Nightly 68.0a1(2019-03-19)(64-bit).
Please reach out if you need any more information, Thank you!
Comment 1•6 years ago
|
||
Hi @adrian, please add accurate steps what is needed to do for test this issue. For example those files from Github need to be downloaded then added into a HTML file then loaded into Firefox? Thanks
Correct, the following steps are for the material design example.
- Download the following markup and save as an html file.
- Turn High Contrast Mode on.
- Load html file in Firefox Quantum (57) or above.
Comment 4•6 years ago
|
||
Hi @Adrian, thanks for the supplied info's. I've retested this issue and here is my results:
1st scenario
[Platform affected]: Windows 10
[Firefox versions affected]: release version 66.0.1 and below
- the issue cannot be reproduced on beta 67.0a1 and latest nighlty 68.0a1
2nd scanario:
[Platform affected]: Mac OS X
[Firefox versions affected]: latest nighlty 68.0a1, beta 67.0a1, release version 66.0.1 and below
- the issue cannot be reproduced on Ubuntu 16.04
Additionally I've run a mozregression and here are the results:
1st bad build: build_date: 2018-09-17 | changeset: 87a95e1b7ec691bef7b938e722fe1b01cce68664
last good build: build_date: 2018-03-31 | changeset: 3f9a70b125f6fb9be2b209159657fd7ae5515c01
pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3f9a70b125f6fb9be2b209159657fd7ae5515c01&tochange=9dcde577687cd5519b2156728f033c322e142a51
Bug 1418616 - Add default extension to downloads saveAs dialogs, r=rpl
Comment 5•6 years ago
|
||
The priority flag is not set for this bug.
:jimm, could you have a look please?
Updated•6 years ago
|
Comment 6•5 years ago
|
||
I recently ran into a similar issue and filed it as bug 1620344, with a bit more investigation/info and a pretty reduced testcase. I think this may be a version of the same issue; marking as a dependency for now.
Comment 7•5 years ago
|
||
Bugbug thinks this bug is a regression, but please revert this change in case of error.
Updated•2 years ago
|
Description
•