Closed Bug 301321 (update403) Opened 19 years ago Closed 19 years ago

Manual update URL is a 403

Categories

(Toolkit :: Application Update, defect)

Product:
Toolkit
Component:
Application Update
Version:
1.8.0 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.8final

People

(Reporter: elfguy, Assigned: rebron)

References

(
URL
)

Details

(Keywords: verified1.8, Whiteboard: [web design in progress, will be ready for tuesday])

Attachments

(1 file)

manual update page screenshot v1 (still needs "simply" removed)
76.12 KB, image/png
Details 
This is the URL currently linked by the update feature in 1.1 alpha builds. It
should redirect to the proper update page instead of giving a 403 error.

*** This bug has been marked as a duplicate of 299482 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
I'm not sure how this is a duplicate. The issue isn't with the fact that the
update system doesn't point to the right spot, the issue is the web server
itself should redirect http://www.mozilla.org/update/ to
http://www.mozilla.org/products/firefox/
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
(In reply to comment #2)
> I'm not sure how this is a duplicate. The issue isn't with the fact that the
> update system doesn't point to the right spot, the issue is the web server
> itself should redirect http://www.mozilla.org/update/ to
> http://www.mozilla.org/products/firefox/

Why should it redirect? The whole purpose of using the different URL for now is
that the update system is disabled by default when it is enabled the update
system will be placed at the default url and no redirect will be necessary. This
is why the release notes list the new update system as currently disabled.
Confirming. The issue here is that the URL given if updates FAIL returns a 403
error. It /should/ redirect to the http://www.mozilla.org/products/firefox/ as
stated by the reporter. 

Just to clarify, the dialog says: 
"You can update Deer Park manually by visting this
link and downloading the lastest version: 

http://www.mozilla.org/update"

So it makes sense for this to go to a valid URL if the update fails, etc.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: [403] error at http://www.mozilla.org/update/ → Manual update URL is a 403
Please ignore comment 3 I misunderstood the purpose of the url. Sorry for the
confusion.

I'm not sure it should redirect to the standard firefox page, I think its
probably intended to add a relevant page to that location in due course.
*** Bug 301366 has been marked as a duplicate of this bug. ***
*** Bug 301909 has been marked as a duplicate of this bug. ***
*** Bug 299095 has been marked as a duplicate of this bug. ***
*** Bug 302860 has been marked as a duplicate of this bug. ***
*** Bug 303273 has been marked as a duplicate of this bug. ***
*** Bug 303374 has been marked as a duplicate of this bug. ***
*** Bug 303455 has been marked as a duplicate of this bug. ***
*** Bug 303853 has been marked as a duplicate of this bug. ***
*** Bug 304138 has been marked as a duplicate of this bug. ***
*** Bug 304432 has been marked as a duplicate of this bug. ***
*** Bug 305283 has been marked as a duplicate of this bug. ***
*** Bug 305316 has been marked as a duplicate of this bug. ***
*** Bug 305322 has been marked as a duplicate of this bug. ***
*** Bug 305327 has been marked as a duplicate of this bug. ***
*** Bug 305408 has been marked as a duplicate of this bug. ***
Moving to AUS so I can set flags on it.  This is also part of the site that is
controlled by server ops rather than the usual webmaster folks, so leaving it
assigned to them is a bit misleading.
Assignee: mozilla.webmaster → nobody
Component: webmaster@mozilla.org → Systems
Product: mozilla.org → AUS
QA Contact: danielwang → nobody
Version: other → 2.0
ok, that didn't help, there's no flags here either. :|

This should be blocking 1.4beta
OK, had a quick chat with Chase, moving this where it actually needs to go to
get the right peoples' attention now.

Someone from the Software Update team needs to decide what this page is supposed
to do and say so before anyone can fix the server to do the right thing.
Component: Systems → Software Update
Product: AUS → Firefox
QA Contact: nobody → software.update
Target Milestone: --- → Firefox1.5
Version: 2.0 → 1.5 Branch
Flags: blocking1.8b4?
Flags: blocking1.8b4? → blocking1.8b4+
*** Bug 305484 has been marked as a duplicate of this bug. ***
Flags: blocking1.8b5+
*** Bug 305762 has been marked as a duplicate of this bug. ***
Assignee: nobody → rebron
Status: NEW → ASSIGNED
Volunteering myself to help with the "what this page should do / say" thing.
Assuming that at this point the possibility of an incremental update is gone,
the page should:

 - look like a standard mozilla.org page
 - have a very small blurb of text about why the user got sent here
 - have a very big link that allows them to download the latest version
 - have a small link that links to the "what's new in this update" page
   that would otherwise have been linked to in the update dialog

I'm thinking something like ..:

Manual Software Update
======================
  If you've experienced problems with the automatic software update, or simply
  prefer to do it yourself, please follow the link below to get the latest
  version of Firefox. Once your download is complete, simply install it over
  your existing version.

  [big link to proper version as detected by user-agent string]

  Find out <link-to-what's-new>what's new in this version</link>
(In reply to comment #26)
>   [big link to proper version as detected by user-agent string]

This won't work for Thunderbird updates (I assume the page will be launched in
the default browser).

If the url given in the update dialogue included the product name and the
version to update from, for example
http://www.mozilla.org/update/thunderbird/1.5 , there'd be no need to do any
user-agent detection.

If app.update.channel is set to nightly, the url could be
http://www.mozilla.org/update/firefox/1.6a/nightly in order to offer an update
to the latest nightly.
I agree sending the mass of our audience for a product to a webpage of our
latest official release and to a page with only that release is better than
giving them 2 or more releases to choose from, so server-side tricks are worth
considering but let's not bet the farm on it or if we want that let's get web
admins in the loop asap.  Time is short.  I like beltzner's approach, not sure
how it meshes with Thunderbird.

Setting separate manual update URLs per product would address the 1.8b4
blockingness aspect of this bug (IMO) and give us breathing room to fix
server-side if need be.
*** Bug 306715 has been marked as a duplicate of this bug. ***
How about we do something like what Beltzner suggests, but providing the user
the option of select which product they would like to update?  This is a
fallback for software update and so we don't *need* to anything too fancy, just
ensure that we're pointing people in the right direction.

Requirements:
 - look like a standard mozilla.org page
 - have a very small blurb of text about why the user got sent here
 - have a very big link that allows them to download the latest version [of
either Firefox or Thunderbird]
 - have a small link that links to the "what's new in this update" page
   that would otherwise have been linked to in the update dialog [for each of
these products]

----
Manual Software Update
======================
  If you've experienced problems with the automatic software update, or simply
  prefer to do it yourself, please follow the link below to get the latest
  version of Firefox or Thunderbird. Once your download is complete, simply
  install it over your existing version.

  Firefox
  [bouncer link to latest version of Firefox]
  Find out <link-to-what's-new>what's new in this version of Firefox</link>

  Thunderbird
  [bouncer link to latest version of Thunderbird]
  Find out <link-to-what's-new>what's new in this version of Thunderbird</link>
---

review?(cbeard) or (beltzner)
http://www.mozilla.org/update/

nit: we use the word "simply" twice in a row; suggest following edit:

- "If you've experienced problems with the automatic software update, or simply
prefer to do it yourself,"

+ "If you've experienced problems with the automatic software update, or are
manually updating the software,"

question: I'm asserting that the user can just install the new version over top
of the old, which I know to be true for Windows and MacOS X, but I'm not sure is
true of Linux. Can I get a confirmation from someone that we're not misleading
users? It might be easiest just to remove the whole second sentence :)

(yes, I know it was my text originally .. :)
In many cases installing over an old build should work fine.  That said, maybe
it'd be good to just point users at the installation instructions :)
darin@meer.net:
"In many cases installing over an old build should work fine.  That said, maybe
it'd be good to just point users at the installation instructions :)"
well yes, but due to the fact that you are overwriting the old directory without
removing the old one first, it's entry will still show up in add/remove programs
on windows, which can be quite annoying because then if you later click to
uninstall the old version it uninstalls the new one and then you still have its
entry in the add/remove programs thing. I would really prefer something that
perhaps only updates the parts needed to be updated to reduce the file size and
reduce confusion in add/remove programs. this would also need to update the
version number in add/remove programs or just remove that entry and create a new
one that works like that. i'm sure there's a way to do it.
ibrahim: yes, it's a long standing bug that the installer doesn't clean up old
registry keys properly when over installing.  we're going to have that problem
when users upgrade from Firefox 1.0 to Firefox 1.5, but we've been having that
problem as folks apply security updates to Firefox 1.0.  so, basically it's par
for the course at the moment.  we should try to fix it going forward, but it
doesn't have to hold us up here.
(In reply to comment #33)
>In many cases installing over an old build should work fine.  That said, maybe
>it'd be good to just point users at the installation instructions :)

I'd rather keep the text here simple and to the point. They can get installation
instructions through the "What's new" link. Uber-novice users won't be on Linux
anyway, and as mentioned w32 and macosx are fine to copy overtop (I've tested
both myself, see below)

(In reply to comment #34)
> removing the old one first, it's entry will still show up in add/remove 

Actually, I'm pretty sure that it doesn't, at least not on XP (Darin, are you
sure that it does?) I installed newer versions over top of older versions all
the time when I was updating along the 1.0.x product line, and only have 1.0.6
in my Add/Remove list. I think the installer roots out the old version or the
uninstall file overwrites the old one or something.

> entry in the add/remove programs thing. I would really prefer something that
> perhaps only updates the parts needed to be updated to reduce the file size 

That's the eventual goal, I think. Well, the eventual goal is to not have
Software Update fail, and thus allow binary patching.

Tell you what, make the "simply" change detailed above, and keep the second bit
in. With that, r=mike.
yeah, i agree it's not critical since most people won't go to uninstall it from
add/remove programs. and i know, because i did that with 1.0.3, installed it
over 1.0.2, then removed 1.0.2 and i lost 1.0.3 which was annoying to say the
least. if this is just an issue of removing a registry key than that's cool, and
we don't need to worry about it. oh, i didnt notice the 403 was fixed, but yeah,
remove the second simply it's awkward. although i think it could be slightly
better, it's pretty good as it is. much better than getting a 403. it adheres to
the KIS standard, and I like it.
> Uber-novice users won't be on Linux anyway

Linux is least likely to have problems with over-installing.  The problem
historically has been with .zip and .tar.gz builds, but with the Mozilla 1.8
branch, those problems should all be history.  The update service basically is
equivalent to unzipping a .zip build of Firefox on top of the old directory, so
I'm pretty confident that over installing an old build is okay now-a-days.

I was more worried about the windows installer because it does stuff outside the
Firefox application directory.  It turns out that you are correct about the
Add/Remove programs business.  It doesn't have a problem there.  Where I see
left-over registry keys is under HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla\, but those
are pretty benign.
mockup of manual update page
Attachment #194736 - Attachment description: manual update page screenshot v1 → manual update page screenshot v1 (still needs "simply" removed)
Whiteboard: [web design in progress, will be ready for tuesday]
page is live, matches screenshot except I removed the first "simply" per beltzner.  
marking fixed, reopen if text needs editing or additional page changes.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → FIXED
Keywords: fixed1.8
i was just wondering whether this detects the current version installed on a
computer, because say someone uses that site to test nightlies, if they went to
it they would get an older version. going to it in deer park alpha 2 gives me
the 1.06 updates, which is not a good thing. i know sometimes user agent gets
spoofed, but it should at least check if someone is running a nightly or
something and show them the latest nightly/alpha/beta along with the latest
stable. on the other hand, a thing asking if perhaps they accidentally
downloaded the nightly and wanted the latest stable would be good too.
(In reply to comment #41)

Yeah, that would be a nice enhancement, but not anything we should rush to do.
Beta testers and nightly testers will be smart enough to assume that the page
we've got up here it to support the 90% user who's not running betas or nightlies :)
Status: RESOLVED → VERIFIED
Keywords: fixed1.8 → verified1.8
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: