1723318 - "Update Available" pop-up should list new version number, link to update info

Status: RESOLVED WONTFIX

(Toolkit :: Application Update, enhancement)

Description

[MarjaE]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:91.0) Gecko/20100101 Firefox/91.0

Steps to reproduce:

1. Stopped automatic updates.

2. Get the annoying pop-up several times each day.

Actual results:

3. Not get any info on what's in each update, what bug fixes are implemented, whether this one will break printing, etc.

Expected results:

4. Should get this info:

https://www.mozilla.org/en-US/firefox/90.0.2/releasenotes/

Comment 1

[Simona Badau, Desktop QA, PTO 13-25aug]

Thank you for the report! Marking this as a new Enhancement and moving over to the Application Update component (if this is not the right one, please move to a more appropriate one).

Comment 3

[Shane Hughes [:aminomancer]]

This isn't a duplicate of my bug. My bug is requesting that the version number and/or date of a staged update be included in the app menu banner, not in the update notification popups. Also, this bug is requesting that release notes be added to the popups too, not just the version or date. Totally different things, but both worthy of consideration imo.

@MarjaE, If you want to get rid of the update popups, you can at least use my script. The goal is just to reduce the amount of popup nuisances for users who disable automatic updates. It replaces update popup notifications with badge/banner-only notifications, e.g. you get the same behavior that you'd normally get after dismissing the popup. Technically the mod just makes it so the notification starts dismissed.

As for adding information about the update to the popup notification, unfortunately it's a lot more complicated. The kind of information that gets sent to the popup or the app menu notification is stripped down by UpdateListener.jsm. That module knows what the version number and date are, it could conceivably get access to release notes, and it could just send the entire update object that the show*Notification functions accept as parameter from the listener. That object already contains everything in question except for a string representation of the release notes.

But for some unknown reason, people seem to think having convenient access to update information is some kind of ostentatious luxury to be abstained from, like firefox is a browser for ascetic monks or something. It's not really a marginal issue either, because even if you open the "About" dialog (e.g. via app menu > help > about firefox), you can't even get a link to the release notes for the staged update; only a link to the notes for the current version.

In other words, there simply is no affordance readily available to give you the necessary information to decide whether to immediately install the staged update, except for typing your own search query into the url or search bar. Right now I'm on 93 and being prompted to update to 94. Clicking "What's new" link directly under the "Update to 94" button, and to the right of the current version label, of course takes me to the notes for 93, the version I already have. The same is true for the update interface in about:preferences. Of course this is still useful information to have after an update, but at the very least when an update has been staged, a link to the release notes for the staged update should be added to the "About" dialog and about:preferences. imo it should be added to the popup notification itself.

The only reasonable conclusion I can draw is that repeatedly searching "firefox release notes" is supposed to build character. Anyway, because the module containing these callbacks is in this particular directory, registered with a resource:// URL, it can't be replaced by the user with autoconfig invoking the component registrar autoRegister function. So it's basically completely opaque to any kind of user modification.

I wanted to make a user modification to add exactly the features you're talking about, but as yet I believe it's impossible to change that listener behavior without rebuilding firefox yourself, or modifying files in the installation directory. It could technically be done by setting up another, separate listener along similar terms, and modifying AppMenuNotifications functions so that they know to ignore the notifications dispatched by the original, built-in listener. But this seems like such a sloppy workaround so I skipped it. I wasn't sure how many other people were bothered by the lack of update information since I don't really solicit feedback.

But now maybe I'll give that another try, especially if I can find a way to display the actual release notes within the UI, rather than simply a link to the release notes. Maybe there's some address that returns the release notes in json or xml form? A third-party RSS feed? If anyone knows where I might be able to programmatically retrieve release notes text from, without having to decipher the regular end-user webpage linked by MarjaE, I'd love to know. Anyway, I'll post again here if I work out a solution.

Comment 4

[Shane Hughes [:aminomancer]]

Another suggestion I'd like to offer, in lieu of my first proposal to add version number to the banner, is that a small secondary button or text link for release notes be added inside the app menu update banner. Similar to how a small "sign in" button is shown in the fxa banner/button when the profile is not signed in. I think for most users, a link to release notes for the staged update would be more valuable than the update's version number. Likewise, at the very least a version number, date, and link to release notes should be added to the update notification popup, so users can know whether something important is going to change (or a user modification is going to break) as soon as they click the button.

I think that would be worth doing for every species of update notification type except "update downloading." It's especially worth doing for the update unsupported notification. Not that I've ever seen it in the wild myself, but I imagine if I did, I'd want to immediately investigate what went wrong. It would be very easy to implement both of these ideas if everyone agreed it's worth doing. I'm 100% willing to contribute the code myself if someone else can submit it. (I can't get mach working)

Comment 5

[Robin Steuber (she/her) [:bytesized]]

I'm afraid that the issue isn't a coding issue. The issue is that our Product team decides how Firefox looks.

If this weren't a busy time for them, I'd be happy to spend some time talking to them about concerns with the design and discussing the possibility of changing it slightly. But they are incredibly busy right now, and they just recently re-designed this interface. This is how they want it to look and it is their decision to make.

I'm sorry that you are unhappy with this decision, but we are simply unable to satisfy everyone.

If you want help developing on Firefox, I would be happy to help you. But I will not be able to approve a patch for this.

Comment 7

[MarjaE]

The issue is that our Product team decides how Firefox looks.

I thought we were supposed to file bug reports here. If we're supposed to file them elsewhere, then where?

Comment 8

[Robin Steuber (she/her) [:bytesized]]

This is where you are supposed to file a bug. But sometimes the response to your bug is going to be "This is not a bug; this is by design". And this is one of those cases. I'm sorry.