See consumers at https://searchfox.org/mozilla-central/search?q=%3Cupdateheader&path=. The page can be seen at chrome://mozapps/content/update/updates.xul, although I'm not sure if/how this can be triggered in the Firefox UI.

(In reply to Brian Grinstead [:bgrins] from comment #2)

See consumers at https://searchfox.org/mozilla-central/search?q=%3Cupdateheader&path=. The page can be seen at chrome://mozapps/content/update/updates.xul, although I'm not sure if/how this can be triggered in the Firefox UI.

I asked around and looked into this some more, and AFAICT we might be able to actually remove updates.xul (which appears to have been removed as the default UI for updates in Bug 596813), instead of changing the UI inside of it.

There's quite a number of references to the window (https://searchfox.org/mozilla-central/search?q=URI_UPDATE_PROMPT_DIALOG&redirect=false), but I guess that's only used if app.update.altwindowtype isn't set to Browser:About. Robert, does this sound right?

Jorg, does TB use the updates.xul window for updates or the About dialog instead? I don't see anything in comm-central that looks different from m-c here.

(In reply to Brian Grinstead [:bgrins] from comment #3)

Jorg, does TB use the updates.xul window for updates or the About dialog instead? I don't see anything in comm-central that looks different from m-c here.

Thanks for the heads up. Moving NI to two people who will know more.

TB uses normally the About dialog for manual updates. But I think, when a update is available and TB asks what to do, then the updates.xul is used.

(In reply to Richard Marti (:Paenglab) from comment #5)

TB uses normally the About dialog for manual updates. But I think, when a update is available and TB asks what to do, then the updates.xul is used.

Hm OK, maybe Firefox does this as well and I just haven't seen it. Robert, in addition to the question in Comment 3: is there a way to simulate an update being available for testing this locally?

There are only a couple of use cases for updates.xul / updates.xml and last I checked TB doesn't use them except for the same cases that Firefox uses them neither of which are for update checks. I plan on removing it entirely once I implement the couple of cases where it is still used. Can you hold off for a couple of weeks? I'll need to get UX involved for some of it.

(In reply to Robert Strong (Robert he/him) [:rstrong] (use needinfo to contact me) from comment #7)

There are only a couple of use cases for updates.xul / updates.xml and last I checked TB doesn't use them except for the same cases that Firefox uses them neither of which are for update checks. I plan on removing it entirely once I implement the couple of cases where it is still used. Can you hold off for a couple of weeks? I'll need to get UX involved for some of it.

Moving the use cases to other, more commonly seen UI and then removing the document makes a lot of sense to me. A couple weeks is perfectly fine for our timeline.

(In reply to Brian Grinstead [:bgrins] from comment #8)

(In reply to Robert Strong (Robert he/him) [:rstrong] (use needinfo to contact me) from comment #7)

There are only a couple of use cases for updates.xul / updates.xml and last I checked TB doesn't use them except for the same cases that Firefox uses them neither of which are for update checks. I plan on removing it entirely once I implement the couple of cases where it is still used. Can you hold off for a couple of weeks? I'll need to get UX involved for some of it.

Moving the use cases to other, more commonly seen UI and then removing the document makes a lot of sense to me. A couple weeks is perfectly fine for our timeline.

Do you want to handle that work in this bug or were you tracking this somewhere else already?

I'm doing this in other bugs... for example, bug 1521427

(In reply to Robert Strong (Robert he/him) [:rstrong] (use needinfo to contact me) from comment #10)

I'm doing this in other bugs... for example, bug 1521427

OK, thanks!

Sorry for taking so long to come back to this.

There are two remaining notifications that need to be changed to doorhangers and the overall work for this is tracked in bug 1521628.

bug 1521427 has a patch ready for review.
bug 1549242 (Thunderbird) has a patch ready for review.
bug 1521632 will hopefully be ready sometime in the next week.
bug 1549309 (Thunderbird) should be fixed soon after bug 1521632.

After that I'll work on removing the old UI.

To get this to move forward faster I've created a simple UI that doesn't use the wizard or xbl for the Elevation UI on Mac. The UI attempts to look the same as the existing UI though I did fix a couple of the most glaring bugs with its current state. This way no strings are needed or UI design to fix this bug. The Elevation UI will be rewritten in bug 1521632.

The screenshot I've attached show the new UI on all platforms in the middle. The current UI is to the left of the new UI and the original UI is on the right so it is possible to see the differences between them. The original UI didn't have the elevation UI so I don't have reference images and since the UI is not shown on Linux or Windows I didn't create current UI images and instead used screenshots of other UI that is available on those platforms for comparison.

Adds a simple UI with tests for the elevation UI that mimics the wizard based elevation UI and uses the existing strings
Removes all methods from nsIUpdatePrompt except showUpdateHistory which will be removed later
Does not remove the UPDATE_WIZ_LAST_PAGE_CODE telemetry histogram since that will remove it from the data sources

https://hg.mozilla.org/mozilla-central/rev/62e0ef6e50dd