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.

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?

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

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?

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

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?

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);
      }
    }

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.

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

https://hg.mozilla.org/mozilla-central/rev/3a710ef2d3ff