1531338 - Current permission for block autoplay is not visible in Site information panel with high contrast enabled

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect, P2)

Description

[Daniel Cicas [:dcicas], Release QA]

Attachment: screenshot with the issue

Affected versions
*Fx 66.0b11

Affected platforms

• Ubuntu 18.04 x64 LTS

Steps to reproduce

1. Enable High Contrast in Ubuntu
2. Open Firefox.
3. Reach https://edition.cnn.com/videos
4. Open the site information panel.
5. Click on the autoplay Allow/Block drop down menu.

Expected result

• The drop down menu displays the current setting and the Allow/Block settings

Actual result

• The drop down menu only displays the Allow/Block, and the current setting is not visible because its black text on a black background.

Regression range

• Will return ASAP with a regression range.

Comment 1

[Johann Hofmann [:johannh]]

Seems more like a general issue with these menulists.

Comment 2

[Oana Botisan, Desktop QA]

I don't think this is a regression. I can reproduce the issue on Nightly from 2019-01-23 when the dropdown menu was first implemented.

Comment 3

[Liz Henry (:lizzard) (relman/hg->git project)]

I'd like to see us fix the bigger issue here, even if this doesn't block rollout of the feature.

Given that this affects accessibility of a set of menus, can you bump the priority up higher than P3?

Comment 4

[Dão Gottwald [:dao]]

Stransky or karlt, any idea how this should be fixed? See bug 334462 for a similar issue -- the patch there may have broken this, actually. I'm not sure that patch makes sense at all anymore for gtk3. Should we revert it?

Comment 5

[Karl Tomlinson (:karlt)]

The same issue exists with data:text/html,<button>Press%20and%20Hold
I expect we want a -moz-buttonactivetext, but we only have a -moz-mac-buttonactivetext.

Comment 6

[Martin Stránský [:stransky] (ni? me)]

I see that was fixed on mac by hardcoding 0xff color to -moz-mac-buttonactivetext. (https://bug1044595.bmoattachments.org/attachment.cgi?id=8501083)

As the system Gtk+ theme colors can't be used here I expect we should do something similar on Linux/Gtk+.

Comment 7

[Dão Gottwald [:dao]]

Mac has basically only one system theme to deal with, Gtk doesn't... I don't see how this could be solved by hardcoding some specific value.

Comment 8

[Martin Stránský [:stransky] (ni? me)]

I have almost working patch. It's a general issue with wrong button text color.

Comment 9

[Martin Stránský [:stransky] (ni? me)]

Attachment: Bug 1531338 - [Linux/Gtk] Get and use Gtk theme text color for active/pressed button, r=dao

• Follow Gtk and get theme button text color directly from "button" CSS node instead of "button label"
• Provide new -moz-gtk-buttonactivetext color for active/pressed button text color
• Replace ButtonText color with -moz-gtk-buttonactivetext when it's appropriate

Comment 10

[Martin Stránský [:stransky] (ni? me)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=3b8c3937742b314f06898d483364b5b168974640

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/39e6fc05451a
[Linux/Gtk] Get and use Gtk theme text color for active/pressed button, r=dao,emilio

Comment 12

[Cristian Brindusan [:cbrindusan]]

https://hg.mozilla.org/mozilla-central/rev/39e6fc05451a

Comment 13

[BugBot [:suhaib / :marco/ :calixte]]

Since the status are different for nightly and release, what's the status for beta?
For more information, please visit auto_nag documentation.

Comment 14

[Julien Cristau [:jcristau]]

Please request uplift to beta if you deem it appropriate.

Comment 16

[Martin Stránský [:stransky] (ni? me)]

It would be nice to have it in next ESR line but it also needs uplift of Bug 1554433. Emilio, is also okay to uplift it?

Comment 17

[Emilio Cobos Álvarez (:emilio)]

I think it should be ok to uplift that, yeah, it's a pretty automatic refactoring, and it only hides the value that was just introduced so it's not web-observable (and thus not really risky).

Let me know if you want me to do the request, but you can also do that :)

Comment 18

[Martin Stránský [:stransky] (ni? me)]

Comment on attachment 9063907 [details]
Bug 1531338 - [Linux/Gtk] Get and use Gtk theme text color for active/pressed button, r=dao

Beta/Release Uplift Approval Request

• User impact if declined: When high contrast Gtk theme is used (for accessibility for instance) various Firefox buttons are not readable - they're completely black. It affects Site autoplay permissions, customizations and more.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: - Enable HighContrast system Gtk theme in tweaks

• Launch Firefox, check button colors are correct in Customize and site permissions page.

• List of other uplifts needed: Bug 1554433
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Gtk/Linux theme bug only.
• String changes made/needed: none

Comment 19

[Julien Cristau [:jcristau]]

Comment on attachment 9063907 [details]
Bug 1531338 - [Linux/Gtk] Get and use Gtk theme text color for active/pressed button, r=dao

gtk theme fix, approved for 68.0b9

Comment 20

[Julien Cristau [:jcristau]]

https://hg.mozilla.org/releases/mozilla-beta/rev/1176df94118f

Comment 21

[Daniel Cicas [:dcicas], Release QA]

Attachment: SS on 86.0b9

Hello,
I investigated this issue on Fx 68.0b9 and on the latest Nightly 69.0a BuildID: 20190610214846. This issue is still occurring on both builds.

Comment 22

[Martin Stránský [:stransky] (ni? me)]

(In reply to Daniel Cicas [:dcicas], Release QA from comment #21)

Created attachment 9071272 [details]
SS on 86.0b9

Hello,
I investigated this issue on Fx 68.0b9 and on the latest Nightly 69.0a
BuildID: 20190610214846. This issue is still occurring on both builds.

You're right. Looks like the latest changes in the patch actually broke the dropdown although other issues addressed by this patch are fixed. Filed as Bug 1558743.