Closed Bug 1333787 Opened 7 years ago Closed 6 years ago

browserAction text color changes to be unreadable when window is inactive

Categories

(Toolkit :: Themes, defect, P3)

Desktop
macOS
defect

Tracking

()

VERIFIED FIXED
mozilla63
Tracking Status
firefox63 --- verified
firefox64 --- verified

People

(Reporter: Fallen, Assigned: arshadkazmi42, Mentored)

Details

(Keywords: good-first-bug, Whiteboard: [triaged])

Attachments

(4 files, 1 obsolete file)

Attached image Screenshot - v1 (obsolete) —
I am using a browserAction button with a red background, which results in a white text. When the window is not focused, the text color changes to a shade of gray, which is really unreadable.

As there is no way to change the text color, let alone the text color while inactive, I think there are two options:

1) Keep the original text color for inactive windows (this is what Chrome does)
2) Extend the API to allow specifying a text color (and an inactive text color)

Workarounds suggest drawing the text on a canvas and using an icon, but that doesn't really sound like a solution to me.
Attached image Screenshot - v2
Wow that was a really bad screenshot. New graphics program not behaving like I expect.
Attachment #8830357 - Attachment is obsolete: true
need UX input on how bad/if we need to fix/what to do if we need to fix
Flags: needinfo?(mjaritz)
Whiteboard: need UX
Oh wow, that is not readable. Please keep the original text color. Seams like a more direct approach to what achieve readability.
Flags: needinfo?(mjaritz)
Whiteboard: need UX
Priority: -- → P5
Whiteboard: [triaged]
Keywords: good-first-bug
Mentor: mwein
Matt, could you please add some information on how to get started? Thanks!
Flags: needinfo?(mwein)
If this is your first contribution, please see https://wiki.mozilla.org/Add-ons/Contribute
Could you provide a sample WE with STR? When I try to reproduce locally (in Nightly 54.0a1), the badge text becomes black and white when the window is inactive.
Flags: needinfo?(mwein) → needinfo?(philipp)
Attached file Testcase - v1
I totally thought I already attached this a few hours ago, so please excuse if I randomly attached it to another bug. I've attached a WebeExtension where this happens.

I think there is also some race condition, because 3 out of 10 times when running with web-ext run I had the same behavior that you did. In those cases the color from the background script was not loaded into the toolbar button, so the default CSS applied (which has a nice inactive state).

If the badge is not green when you load this add-on, try reloading the add-on.
Flags: needinfo?(philipp)
Thanks.

It looks like the selector we'll want to update is here: http://searchfox.org/mozilla-central/source/toolkit/themes/osx/global/toolbarbutton.css#100. I don't see this selector used for Windows or Linux, so I suspect that this issue only occurs on Mac.
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INACTIVE
Status: RESOLVED → REOPENED
Resolution: INACTIVE → ---
Mentor: matthewjwein → ntim.bugs
Product: Toolkit → WebExtensions
If this is your first contribution, please see how to onboard to the Firefox codebase: https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Introduction
It doesn't look like anyone else is working on this, I'll put together a patch.
(In reply to Jake Nixon from comment #12)
> It doesn't look like anyone else is working on this, I'll put together a
> patch.

Awesome! Thanks, Jake. I'll assign this bug to you. Feel free to needinfo :ntim, the mentor for this bug, if you need any help!
Assignee: nobody → jake.zachariah.nixon
(In reply to Caitlin Neiman [:caitmuenster] from comment #13)
> (In reply to Jake Nixon from comment #12)
> > It doesn't look like anyone else is working on this, I'll put together a
> > patch.
> 
> Awesome! Thanks, Jake. I'll assign this bug to you. Feel free to needinfo
> :ntim, the mentor for this bug, if you need any help!

Thanks, will do!
Hey Jake, any update on this? Let me know if you need help.
Flags: needinfo?(jake.zachariah.nixon)
(In reply to Tim Nguyen :ntim from comment #15)
> Hey Jake, any update on this? Let me know if you need help.

Hi Tim,

Sorry for the delay, have been snowed under at work. Will be looking at this tonight.
Flags: needinfo?(jake.zachariah.nixon)
Is Jake still working on this? 
Or I can take this up
Flags: needinfo?(ntim.bugs)
(In reply to Arshad Kazmi from comment #17)
> Is Jake still working on this? 
> Or I can take this up

Apologies, have had other commitments at work. Please feel free to work on this.
Assignee: jake.zachariah.nixon → arshadkazmi42
Flags: needinfo?(ntim.bugs)
Made changes as mentioned in Comment 10.
Pushed code to phabricator

https://phabricator.services.mozilla.com/D4635
Flags: needinfo?(ntim.bugs)
Looks fine to me, I've redirected the review to :dao.
Flags: needinfo?(ntim.bugs)
Thank you Tim. I will wait for review from dao
Component: Frontend → Themes
Priority: P5 → P3
Product: WebExtensions → Toolkit
Comment on attachment 9005095 [details]
Bug 1333787 - BrowserAction TextColor on Inactive Window

Dão Gottwald [::dao] has approved the revision.
Attachment #9005095 - Flags: review+
Keywords: checkin-needed
Pushed by dgottwald@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/bc21091cba69
BrowserAction TextColor on Inactive Window r=dao
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/bc21091cba69
Status: REOPENED → RESOLVED
Closed: 6 years ago6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla63
Flags: qe-verify+
Hi guys,
I'm sorry to be the noob, but could you give me a straight-forward STR I can check? I can't seem to deduce the reproduction, including actual and expected results of this bug.
Thank you. :)
Flags: needinfo?(philipp)
Flags: needinfo?(arshadkazmi42)
sorry, but what is STR? I am not good with short forms :P
Flags: needinfo?(arshadkazmi42) → needinfo?(daniel.bodea)
STR is an abbreviation for "Steps To Reproduce", also known as reproduction steps. Sorry for the confusion. :)
Basically, I don't know how to reproduce the issue on an affected build, so then I could verify it on a fixed build.
Thanks!
Flags: needinfo?(daniel.bodea)
You can try installing the addon given in attachment above

'Testcase - v1'

after installing this addon in your browser you will get an icon on right top side of browser as given in the screenshot in attachment.

You can find all attachments of this bug, right above the Comment 0 of this bug
I attempted to reproduce and verify this issue, but I was unable. From what I understand, the color of the addon icon's text becomes unreadable when the browser windows is inactive (not focused). Correct?

On Windows and Ubuntu OSes, the text keeps its color when the window is inactive just like when it's active, on both the affected build (2018-08-25) and the fixed one (2018-09-30).
On Mac OS X, the whole toolbar will become grayed out when the window becomes inactive, but I could not see any difference between the affected build and the fixed one.

Given all the above, I need more information on the original issue:
1. Is it specific to a certain OS?
2. What are the actual and expected results? What should I verify exactly? 
3. How (exactly) did the fix change the UI of the browser?
4. Just to be sure... is this issue desktop related? Not mobile, right?
5. Is there anything else I should know in order to verify the issue correctly?

Thank you!
Flags: needinfo?(arshadkazmi42)
> 1. Is it specific to a certain OS?

Yes, it's specific to macOS

> 2. What are the actual and expected results? What should I verify exactly? 

Actual: https://bug1333787.bmoattachments.org/attachment.cgi?id=8830360

Expected: Text color between active and inactive state should not change
Flags: needinfo?(arshadkazmi42)
Understood, Tim. Thank you for clearing it up.
This means that the issue is not fixed in the latest Nightly v64.0a1 from 2018-09-30.
Can you look into it, Arshad Kazmi?

P.S. I will attach a pic demonstrating the active vs inactive states of the addon button in comparison with the original pic, below.
Flags: needinfo?(philipp) → needinfo?(arshadkazmi42)
OS: Unspecified → Mac OS X
Hardware: Unspecified → Desktop
This is a demonstration of the active versus inactive states of the addon button.
(In reply to Bodea Daniel [:danibodea] from comment #32)
> Understood, Tim. Thank you for clearing it up.
> This means that the issue is not fixed in the latest Nightly v64.0a1 from
> 2018-09-30.
> Can you look into it, Arshad Kazmi?
> 
> P.S. I will attach a pic demonstrating the active vs inactive states of the
> addon button in comparison with the original pic, below.

The text color is white for both cases, but the whole badge has a lower opacity.

Whereas before, you have white text on one side, gray text on the other.
Flags: needinfo?(arshadkazmi42)
Considering the comment above, I will set this issue as verified in firefox64. 

Will it be uplifted? I could not find an addon with text on button that I could install on Beta to see if firefox63 is affected.
Flags: needinfo?(ntim.bugs)
(In reply to Bodea Daniel [:danibodea] from comment #35)
> Considering the comment above, I will set this issue as verified in
> firefox64. 
> 
> Will it be uplifted? I could not find an addon with text on button that I
> could install on Beta to see if firefox63 is affected.

This bug landed on 63, so it should be fixed there.

To check, you can try this add-on: https://addons.mozilla.org/en-US/firefox/addon/zoom-page-we/?src=featured
Flags: needinfo?(ntim.bugs)
I have used this addon on Beta v63.0b10 on Mac OS X 10.14 and it has the same effect as on the Nightly browser.
Marking firefox63 as verified. Issue completely verified now.
Thank you!
Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: