1314674 - Background of badge on browserAction button changes to red

Status: VERIFIED FIXED

(WebExtensions :: Frontend, defect, P5)

Description

[dw-dev]

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).

Comment 1

[Andy McKay]

I can't reproduce this at all. Do you have other add-ons or themes that might be causing this?

Comment 2

[dw-dev]

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.

Comment 3

[Andy McKay]

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.

Comment 4

[Luke Crouch [:groovecoder]]

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

Comment 6

[Mark Striemer [:mstriemer]]

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).

Comment 7

[Michal Stanke (Mozilla.cz) [:mstanke][:MikkCZ]]

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 9

[Mark Striemer [:mstriemer]]

Attachment: Bug 1314674 - Maintain badge style in new windows and customize

Review commit: https://reviewboard.mozilla.org/r/182836/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/182836/

Comment 10

[Mark Striemer [:mstriemer]]

Comment on attachment 8911365 [details]
Bug 1314674 - Maintain badge style in new windows and customize

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/182836/diff/1-2/

Comment 11

[Shane Caraveo (:mixedpuppy)]

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.

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/aff6bfbd21ee
Maintain badge style in new windows and customize r=mixedpuppy

Comment 13

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/aff6bfbd21ee

Comment 14

[Michal Stanke (Mozilla.cz) [:mstanke][:MikkCZ]]

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?

Comment 15

[Shane Caraveo (:mixedpuppy)]

Yes, lets request uplift.

Comment 16

[Mark Striemer [: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

Comment 17

[Sylvestre Ledru [:Sylvestre]]

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.