Closed Bug 1515484 Opened Last year Closed 6 months ago

Remove old updates UI

Categories

(Toolkit :: Application Update, task, P3)

task

Tracking

()

RESOLVED FIXED
mozilla69
Tracking Status
firefox69 --- fixed

People

(Reporter: ntim, Assigned: robert.strong.bugs)

References

Details

Attachments

(2 files)

<updateheader label="..."/> could change to:

<vbox class="wizard-header update-header">
  <xul:label class="wizard-header-label" value="..."/>
</vbox>

The styling would need to be adapted to get rid of the extra intermediary containers.
This would allow getting rid of the updateheader binding.
Makes sense. Would also make removing wizard-header easier since it inherits from it - although as per the patch in Bug 1494846 it probably doesn't need to be.
Blocks: 1494846
Priority: -- → P5
See Also: → 1520924
Whiteboard: [xbl-available]

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.

Depends on: 596813
Flags: needinfo?(robert.strong.bugs)
Flags: needinfo?(jorgk)

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

Flags: needinfo?(richard.marti)
Flags: needinfo?(mkmelin+mozilla)
Flags: needinfo?(jorgk)

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.

Flags: needinfo?(richard.marti)

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

Flags: needinfo?(robert.strong.bugs)

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

Summary: Change updateheader binding into markup → Remove updates.xml or change updateheader binding into markup
Whiteboard: [xbl-available]
Flags: needinfo?(mkmelin+mozilla)

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

Flags: needinfo?(robert.strong.bugs)

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

Flags: needinfo?(robert.strong.bugs)

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

Depends on: 1521427
Summary: Remove updates.xml or change updateheader binding into markup → Remove updates.xul or change updateheader binding into markup

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.

Depends on: 1521628
No longer depends on: 1521427
Summary: Remove updates.xul or change updateheader binding into markup → Remove old updates UI
Component: XUL Widgets → Application Update
Type: enhancement → task
Assignee: nobody → robert.strong.bugs
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla69

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.

Blocks: 1552771
No longer depends on: 1552771

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

Pushed by rstrong@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/62e0ef6e50dd
Remove the wizard based app update UI and related code. r=bytesized
Status: ASSIGNED → RESOLVED
Closed: 6 months ago
Resolution: --- → FIXED
QA Whiteboard: [qa-69b-p2]
You need to log in before you can comment on or make changes to this bug.