888648 - Update notification should not be shown or "Check for Updates" hidden for default channel (e.g., Linux distro builds)

Status: NEW

(SeaMonkey :: Startup & Profiles, defect)

Description

[rsx11m]

Bug 581319 introduced a warning ("Your copy of SeaMonkey is old ... but you have disabled automated update checks.") when an installation hasn't been updated for a while. I've got this on a production machine due to the fact that 2.18 was skipped (so was 2.17.1 on OpenSUSE).

However, this is an RPM-based build from the distro's build service, thus it is on the "default" update channel and wasn't disabled by any user action. Thus, the message itself is misleading as the user has no chance to resolve the issue in SeaMonkey itself. Naturally, the "Check for Updates" button does nothing, only throws the following exception:

Error: TypeError: Components.classes['@mozilla.org/updates/update-prompt;1'] is undefined
Source File: chrome://communicator/content/bindings/notification.xml
Line: 1067

Solution: Either omit the notification entirely for the default channel, assuming that some other mechanism will apply, or at least the "Check for Update" button should be hidden in this case.

Comment 1

[rsx11m]

Now that 2.19 has been released, waiting for RPMs to be posted on the OpenSUSE Build Service site at http://download.opensuse.org/repositories/mozilla/ .

Hiding the notification bar could probably be done as a distro-specific patch when creating the RPMs if it's not wanted for the mozilla.org-based releases. It is my understanding that at least OpenSUSE applies a couple of those for other cases already. However, hiding the "Check for Updates" button will remain necessary for the app.update.channel="default" case in the general builds.

Comment 2

[Wolfgang Rosenauer [:wolfiR]]

(In reply to rsx11m from comment #1)
> Now that 2.19 has been released, waiting for RPMs to be posted on the
> OpenSUSE Build Service site at
> http://download.opensuse.org/repositories/mozilla/ 

Should appear very soon now. Just pushed the "publish button".
 
> Hiding the notification bar could probably be done as a distro-specific
> patch when creating the RPMs if it's not wanted for the mozilla.org-based
> releases. It is my understanding that at least OpenSUSE applies a couple of
> those for other cases already. However, hiding the "Check for Updates"
> button will remain necessary for the app.update.channel="default" case in
> the general builds.

I could have sworn there is already a bug about it but cannot find it.
Neither Firefox nor Thunderbird show update messages or offer update checks if the installation directory is not writable. This simple solution seems to work well for them.

Comment 3

[rsx11m]

Interesting, the installation is at its default /usr/lib64/seamonkey location and I definitely don't have write permission to any of the files or directories there.

Comment 4

[Wolfgang Rosenauer [:wolfiR]]

Indeed, And that is an implementation difference to FF and TB and I'd propose to just implement the same behaviour. (I might have time to look into it but no guarantees)

Comment 5

[rsx11m]

Oh, I see. I thought first you were implying that it should equally work in SM already, but that's apparently not the case. The "Check for Updates" menuitem in Help is already hidden with these builds, and the Software Installation pref pane doesn't show the application-update options either, so these parts work fine.

Comment 6

[rsx11m]

Another detail I've missed is that you override app.update.enabled="false" in all-openSUSE.js, which prompts the notification bar to start with. I've toggled it to "true" (which should be safe given that no updates will be found for sure on the "default" channel) and the banner does no longer show up when starting SeaMonkey.

Comment 7

[Wolfgang Rosenauer [:wolfiR]]

Thanks for digging into it. Indeed the app.update.enabled was introduced at a time where the automatic disabling of the UI didn't work I guess. I also have found no sign that setting it to true breaks things. So I'll remove that pref override from the package and this bug can be closed? Did I miss something?

Comment 8

[Mike Hommey [:glandium]]

app.update.enabled does more than enabling the Check update prompt in the UI. It enables automatic checks for updates.

Comment 9

[Wolfgang Rosenauer [:wolfiR]]

I know. That's no problem though since --disable-updater is in place obviously. So app.update.enabled enables a lot of ifdefed-out code

Comment 10

[rsx11m]

(In reply to Wolfgang Rosenauer [:wolfiR] from comment #7)
> So I'll remove that pref override from the package and this bug can be closed?

While that would work around the issue showing up in OpenSUSE builds, which is certainly good, this bug could be refocused to address your comment #2 to avoid showing the notification bar when the installation directory isn't writable for that user (i.e., he or she can't do anything about it other than enabling the automated updates which subsequently would fail, or not?).