Closed Bug 1314674 Opened 3 years ago Closed 2 years ago

Background of badge on browserAction button changes to red

Categories

(WebExtensions :: Frontend, defect, P5)

48 Branch
defect

Tracking

(firefox55 wontfix, firefox56 wontfix, firefox57 wontfix, firefox58 fixed)

VERIFIED FIXED
mozilla58
Tracking Status
firefox55 --- wontfix
firefox56 --- wontfix
firefox57 --- wontfix
firefox58 --- fixed

People

(Reporter: dw-dev, Assigned: mstriemer)

References

()

Details

(Whiteboard: [browserAction]triaged)

Attachments

(1 file)

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
Flags: needinfo?(dw-dev)
Whiteboard: [browserAction]
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.
Flags: needinfo?(dw-dev)
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
Duplicate of this bug: 1395885
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.
Duplicate of this bug: 1401541
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+
Keywords: checkin-needed
Status: NEW → ASSIGNED
Pushed by ryanvm@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/aff6bfbd21ee
Maintain badge style in new windows and customize r=mixedpuppy
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/aff6bfbd21ee
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla58
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
Yes, lets request uplift.
Flags: needinfo?(mstriemer)
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
Flags: needinfo?(mstriemer)
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-
Product: Toolkit → WebExtensions
You need to log in before you can comment on or make changes to this bug.