Closed Bug 1314674 Opened 3 years ago Closed 2 years ago
Background of badge on browser
Action button changes to red
59 bytes, text/x-review-board-request
User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0 Build ID: 20160823121617 Steps to reproduce: I have developed three WebExtensions add-ons (Print Edit WE, Tile Tabs WE and Zoom Page WE) that all have a badge on the browserAction button indicating the state of the add-on. Normally, the badges work fine. However, on entering Customize mode the badge backgrounds all change to red, and on exiting Customize mode the badge backgrounds remain red. Actual results: On entering Customize mode the badge backgrounds all change to red, and on exiting Customize mode the badge background all remain red. Expected results: On entering Customize mode the badge backgrounds should either remain the colors that they were previously or the badges should be hidden. On exiting Customize mode the badge backgrounds should return to the colors that they were previously (before entering Customize mode).
Summary: badge on browserAction button changes to red after exit customize → WebExtensions: Background of badge on browserAction button changes to red on entering and remains red on exiting Customize mode
Component: Untriaged → WebExtensions: Untriaged
Product: Firefox → Toolkit
I can't reproduce this at all. Do you have other add-ons or themes that might be causing this?
Summary: WebExtensions: Background of badge on browserAction button changes to red on entering and remains red on exiting Customize mode → Background of badge on browserAction button changes to red on entering and remains red on exiting Customize mode
Component: WebExtensions: Untriaged → WebExtensions: Frontend
I have re-tested with both Firefox 49.0 and Nightly 52.0a1, installing only my Zoom Page WE 3.0 add-on in a new profile. The reported problem occurs every time I enter/exit Customize mode. I have also re-tested Nightly 52.0a1, installing my Print Edit WE and Tile Tabs WE add-ons in separate new profiles. Again, the reported problem occurs every time I enter/exit Customize mode. The simplest test is: 1. Use Firefox 49.0 or Nightly 52.0a1. 2. Create a new profile. 3. Install Zoom Page WE 3.0. 4. Navigate to the Google home page. 5. The Zoom Page WE button should be showing a badge with a dark grey background and the text "100". 6. Use the Firefox menu panel to enter Customize mode. 7. The badge on the Zoom Page WE button now has a red background. 8. Exit Customize mode. 9. The badge on the Zoom Page WE button still has a red background. 10. Click on the Zoom Page WE button and the badge background returns to dark grey.
Ah thanks, dw-dev I can reproduce, its the text on the browser action that goes red. Red is the default background colour of the text, so this looks like a bug in how setBadgeBackgroundColor works.
Priority: -- → P5
Whiteboard: [browserAction] → [browserAction]triaged
We may have hit the same bug in setBadgeBackgroundColor? The color reverts to the default red in new windows ... https://github.com/mozilla/testpilot-containers/issues/608
See Also: → 1395885
Status: UNCONFIRMED → NEW
Ever confirmed: true
It looks like there are three ways to trigger this: 1. Opening a new window (I can't reproduce this). 2. Resizing so that the icon is hidden, then resize to shown. 3. Entering customize mode (remains after exit).
Assignee: nobody → mstriemer
Summary: Background of badge on browserAction button changes to red on entering and remains red on exiting Customize mode → Background of badge on browserAction button changes to red
Hi Mark. Here is a test add-on, where I can reproduce the first case (opening a new window). Just install it via about:debugging and open a new window. The badge will be read in the new window.
Comment on attachment 8911365 [details] Bug 1314674 - Maintain badge style in new windows and customize https://reviewboard.mozilla.org/r/182836/#review188430 nice! I think this would be fine to request uplift for.
Attachment #8911365 - Flags: review?(mixedpuppy) → review+
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/aff6bfbd21ee Maintain badge style in new windows and customize r=mixedpuppy
Seems to for for me in Mozilla/5.0 (X11; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0 ID:20170927100120. Is this something that could be uplifted to beta?
Status: RESOLVED → VERIFIED
Comment on attachment 8911365 [details] Bug 1314674 - Maintain badge style in new windows and customize Approval Request Comment [Feature/Bug causing the regression]: This code hasn't changed much since it was added in bug 1175770. It likely always had this bug. [User impact if declined]: Badge colours will be incorrect in new windows and upon exiting customize mode. [Is this code covered by automated tests?]: No [Has the fix been verified in Nightly?]: I have manually verified the fix [Needs manual test from QE? If yes, steps to reproduce]: 1. Install an extension that sets the browserAction badge text and colour without a tabId 2. Open a new window 3. Text and colour should remain the same [List of other uplifts needed for the feature/fix]: [Is the change risky?]: Low risk [Why is the change risky/not risky?]: It relies on XUL attribute inheritance rather than inspecting the rendered children. It is a small change [String changes made/needed]: none
Attachment #8911365 - Flags: approval-mozilla-beta?
Any reason why this cannot ride the train with 58? Looks like we have this bug for a while and I would like to limit the number of changes in 57 beta.
Attachment #8911365 - Flags: approval-mozilla-beta? → approval-mozilla-beta-
You need to log in before you can comment on or make changes to this bug.