Closed Bug 1626937 Opened 5 years ago Closed 5 years ago

Check for Updates in Add-ons doesn't show status messages

Categories

(Toolkit :: Add-ons Manager, defect)

76 Branch
x86_64
Windows 10
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla76
Tracking Status
firefox-esr68 --- unaffected
firefox74 --- unaffected
firefox75 --- unaffected
firefox76 --- fixed

People

(Reporter: streetwolf52, Assigned: mstriemer)

References

(Regression)

Details

(Keywords: regression)

Attachments

(3 files)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:76.0) Gecko/20100101 Firefox/76.0

Steps to reproduce:

Go to about:addons in Nightly
Click on the tools icons
Select 'Check for Updates'

Actual results:

Nothing happens. No messages and no updates if they exist.

Expected results:

A notification should be displayed whether there are no updates or an add-on has been updated.

Problem started yesterday. Browser Log appears to show requests for updated. Fx74 does not have this problem.

Component: Untriaged → Add-ons Manager
OS: Unspecified → Windows 10
Product: Firefox → Toolkit
Hardware: Unspecified → x86_64
Priority: -- → P2

Please don't set priority on new bugs, that's done by the folks who triage incoming bugs and they may overlook the bug if you set a priority.

I can't reproduce this on Nightly, updates seem to work fine for me. Is the issue the lack of visual feedback in about:addons after an update check or are updates not actually being applied for you?

Flags: needinfo?(garyshap)
Priority: P2 → --

I direct you here for the answers.... http://forums.mozillazine.org/viewtopic.php?f=23&t=3060743

I believe that updates if they exist are not being applied according to one of the posts

Flags: needinfo?(garyshap)

I created a new profile and then added an add-on. I then tried to update it and received no messages whatsoever.

This is the last good Nightly build from March 31. All Nightly builds after it are borked.

https://hg.mozilla.org/mozilla-central/rev/9af589864188fc4061a020c45914f54fa9f67b0d

The mozillazine thread is light on details or steps to reproduce.
In my local test, updates apply just fine but there is no visual feedback.
Mark, it looks like the <span> inside AddonUpdatesMessage isn't getting its localized string updated, any ideas why? Also, do we have a test of the visual updates here?

Flags: needinfo?(mstriemer)
Summary: Check for Updates in Add-ons does not work in Nightly → Check for Updates in Add-ons doesn't show status messages

The feedback label(Updating add-ons/Your add-ons have been updated/No update found) is not displayed near the gear icon.
(Actually, updating seems to be successfully performed)

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=d34b88ed7c0bb7e8d7c1fb99883370a0c70515aa&tochange=f76a5f5c354b8f1cd363eb91d819d7d8b55c4c09

Has Regression Range: --- → yes
Regressed by: 1617669

gandalf, since bug 1617699, the AddonUpdatesMessage custom element (https://searchfox.org/mozilla-central/source/toolkit/mozapps/extensions/content/aboutaddons.js#1382-1433) isn't getting its text localized when it updates, do you know if there's a simple fix here?

Flags: needinfo?(gandalf)
Status: UNCONFIRMED → NEW
Has STR: --- → yes
Ever confirmed: true

I don't see where Fluent is being connected to the shadow DOM?

You probably need connectedCallback like this: https://searchfox.org/mozilla-central/source/toolkit/content/widgets/wizard.js#114-116

    connectedCallback() {
      if (document.l10n) {
        document.l10n.connectRoot(this.shadowRoot);
        document.l10n.translateFragment(this.shadowRoot);
      }
    }
    disconnectCallback() {
      if (document.l10n) {
        document.l10n.disconnectRoot(this.shadowRoot);
      }
    }
Flags: needinfo?(gandalf)

You meant bug 1617669 for the reference.

There's no test for the visual updates here from what I can tell. If there were updates you would see the button, but it wouldn't have any text.

If there was a test I don't think it would have failed since document.l10n.getAttributes(thatButton) still returns the id that is being set even though it isn't tracking the element.

It looks like this is the only element that was using fluent directly in its shadow DOM.

Flags: needinfo?(mstriemer)
Assignee: nobody → mstriemer
Status: NEW → ASSIGNED

(In reply to Mark Striemer [:mstriemer] from comment #13)

There's no test for the visual updates here from what I can tell. If there were updates you would see the button, but it wouldn't have any text.

Aren't there two cases: auto-updates enabled in which case you see a message and auto-updates disabled in which case you see a button? I'm pretty sure the old about:addons had tests of both these cases, did we lose test coverage during the html migration?

If there was a test I don't think it would have failed since document.l10n.getAttributes(thatButton) still returns the id that is being set even though it isn't tracking the element.

Sure, so a good test would check innerHTML or something instead of just the l10n attribute.

Sure, so a good test would check innerHTML or something instead of just the l10n attribute.

I would argue that a test should be atomic and not test for innerHTML. At least, not for any particular value to allow the test to work in any locale.

(In reply to Zibi Braniecki [:zbraniecki][:gandalf] from comment #15)

Sure, so a good test would check innerHTML or something instead of just the l10n attribute.

I would argue that a test should be atomic and not test for innerHTML. At least, not for any particular value to allow the test to work in any locale.

I'm not sure what atomic means in this context, but testing that there's some text there with length > 0 would be a start. Or maybe checking that the computed width and height of the span are > 0? Seems like there ought to be a reasonable way to write a test that would catch if a regression reintroduced this bug.

Pushed by mstriemer@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/3a710ef2d3ff Explicitly connect the addon-updates-message shadow DOM r=rpl
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla76
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: