Closed Bug 679324 Opened 13 years ago Closed 13 years ago

remove the update channel reference from the about page when the user has no permissions to update anyway

Categories

(Firefox :: General, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
Firefox 9

People

(Reporter: wolfiR, Assigned: gaston)

Details

Attachments

(1 file, 1 obsolete file)

Remove the update channel reference from the about page when the user has no permissions to update anyway.

This information is meaningless for people not having update rights or even the updater code shipped in Firefox builds.
I think there are several things here:
- It's absolutely useless when the update channel is "default"
- It's informative but useless when there is not updater (--disable-updater)
- It's informative but useless when the user doesn't have the necessary rights to upgrade

I also think, but it's more of a long term thing, that distros could have it work through a package manager API or something like that.
(In reply to Mike Hommey [:glandium] from comment #1)
> I think there are several things here:
> - It's absolutely useless when the update channel is "default"
> - It's informative but useless when there is not updater (--disable-updater)

I don't think it's informative. It's a build time information and if not shipping with updater the compiled information is probably wrong anyway.

> - It's informative but useless when the user doesn't have the necessary
> rights to upgrade

If --enable-update then it might be informative because someone else on the system could have the needed permissions and the update channel is of interest.
 
> I also think, but it's more of a long term thing, that distros could have it
> work through a package manager API or something like that.

The information about the "update channel"?
My update channels are
mozilla, mozilla:beta, mozilla:alpha
currently and they are just defined by the configured repositories.
While I'm not against an idea like the above I do not see that something like that will happen just for mozilla.
(In reply to Wolfgang Rosenauer [:wolfiR] from comment #2)
> (In reply to Mike Hommey [:glandium] from comment #1)
> > I think there are several things here:
> > - It's absolutely useless when the update channel is "default"
> > - It's informative but useless when there is not updater (--disable-updater)
> 
> I don't think it's informative. It's a build time information and if not
> shipping with updater the compiled information is probably wrong anyway.

If you're using the "aurora" or "beta" update channels, and use the mozilla update url, i'd expect that message to tell you if you're not using the last version, which is informative. I don't know if that's true, though.
Hmm, that might be a reason to show it but I'm pretty sure it doesn't behave that way at the moment.
I realized the same thing.. as there's already an #ifdef MOZ_UPDATER in browser/base/content/aboutDialog.xul, the 'You are on the xxx update channel' could be included within it. I think it is misleading to say that if the update channel is provided by the os itself, nothing should be shown, or it could say smth along the lines of 'You are on your operating system package manager update channel'.
Landry, the Mozilla code doesn't know if your OS provides updates for this build or not, so we can't really tell the user that, it would be wrong as well (if he's building himself, he gets the exact same "default" channel configuration).

But yes, this probably should be included in another #ifdef MOZ_UPDATER and just not be shown at all.
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #6)
> Landry, the Mozilla code doesn't know if your OS provides updates for this
> build or not, so we can't really tell the user that, it would be wrong as
> well (if he's building himself, he gets the exact same "default" channel
> configuration).

Ah, you're right. That's a different issue..

> But yes, this probably should be included in another #ifdef MOZ_UPDATER and
> just not be shown at all.

That would make perfectly sense to me. How about the attached (totally untested) patch ?
Maybe we want to deal with all the issues at once, but knowing if the user has necessary rights to update the app is another thing.... as for not showing it too if its 'default'.
Attachment #553731 - Flags: review?(kairo)
Comment on attachment 553731 [details] [diff] [review]
Dont show the update channel if the updater is disabled

From my POV, this looks good, but I'm not entitled to doing reviews in that area, forwarding that to Margaret, given she also did the last review affecting this part of code. :)
Attachment #553731 - Flags: review?(margaret.leibovic)
Attachment #553731 - Flags: review?(kairo)
Attachment #553731 - Flags: feedback+
Comment on attachment 553731 [details] [diff] [review]
Dont show the update channel if the updater is disabled

This looks like the right approach. However, it will cause a JS error, since we look for the currentChannel label here: http://mxr.mozilla.org/mozilla-central/source/browser/base/content/aboutDialog.js#92.

I think you should just move that block of code that sets the label value up a few lines to put it inside the #ifdef MOZ_UPDATER block that's currently above it. With that change, this should be good!
Attachment #553731 - Flags: review?(margaret.leibovic) → review-
Something like this should address that issue.. i've checked, and defaults/channelLabel are not used elsewhere in the file, so move the whole block to the #ifdef.
Attachment #553731 - Attachment is obsolete: true
Attachment #554967 - Flags: review?(margaret.leibovic)
Attachment #554967 - Flags: review?(margaret.leibovic) → review+
Keywords: checkin-needed
Assignee: nobody → landry
Fixed missing bug number from commit message; landed on inbound:
http://hg.mozilla.org/integration/mozilla-inbound/rev/f2bc0f933661

Thanks Landry :-)
Status: NEW → ASSIGNED
Keywords: checkin-needed
OS: Linux → All
Target Milestone: --- → Firefox 9
Version: unspecified → Trunk
http://hg.mozilla.org/mozilla-central/rev/f2bc0f933661
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: