Closed
Bug 367913
Opened 17 years ago
Closed 14 years ago
"Details" link in software update dialog leads to meaningless page
Categories
(Toolkit :: Application Update, defect, P5)
Tracking
()
RESOLVED
DUPLICATE
of bug 475671
mozilla1.9beta3
People
(Reporter: marcia, Unassigned)
References
Details
Attachments
(3 files)
Seen while testing the upgrade path from 1.5.0.9->2.0.0.1 using the releasetest channel. STR: 1. Go get the update 2. At the "Ready to Install" dialog click the details link 3. You are led to http://en-us.www.mozilla.com/en-US/firefox/2.0/details/index.html, which shows a jpeg image that is rather meaningless. The page leads to an unattractive jpeg that seems to correspond to the what the image is on the initial presentation of the software update screen.
Comment 1•17 years ago
|
||
That link comes from the detailsURL in the update.xml, which is also used for both the offer of the major update. I'm not sure there is anything that can be done, unless there is some JS or serverside trick that would change the page loaded in the browser but not in the update offer.
OS: Windows NT → All
Hardware: PC → All
Comment 2•17 years ago
|
||
marcia, good catch! did you do this? 1) download the major update 2) when done, do "apply Later" 3) go back to Help | Apply Downloaded Update Now" I'll attach a screen shot. that unattactive details URL is the detailsURL value for a major update. can you see what it points to for a minor update? (I know it's something better, but I can't remember if it is the release notes or something else.)
Reporter | ||
Comment 3•17 years ago
|
||
This is the page that you get when you click on the Details link.
Comment 4•17 years ago
|
||
Comment 5•17 years ago
|
||
confirmed. I see the same on the major update testing. See the screenshot, i clicked on this details link.
Reporter | ||
Comment 6•17 years ago
|
||
Yes, those were my steps to reproduce. For a minor update, such as going from 1.5.0.8->1.5.0.9, that Details link points to http://www.mozilla.com/en-US/firefox/releases/1.5.0.9.html, which is the release notes. (In reply to comment #2) > marcia, good catch! > > did you do this? > > 1) download the major update > 2) when done, do "apply Later" > 3) go back to Help | Apply Downloaded Update Now" > > I'll attach a screen shot. > > that unattactive details URL is the detailsURL value for a major update. > > can you see what it points to for a minor update? (I know it's something > better, but I can't remember if it is the release notes or something else.) >
Comment 7•17 years ago
|
||
as nick points out in comment #1, the detailsURL value is being used in several places, to provide details about the update. this page is used in the small XUL browser inside software update, which is why it doesn't look as right in a big browser window. see also bug #354789, where we'd like to pass something on the query string to change the content returned. for this bug, we could add an additional value to the query string, for "full" or "brief", and full would redirect to something like http://www.mozilla.com/en-US/firefox/features.html.
I like the idea of linking "full" to the existing Features pages. Here's a reference list of the locales for which we have a translated version of the Features page: http://wiki.mozilla.org/Firefox2/Major_Update_Web_Content#Content For those locales not listed on the wiki page above, we should route the user to: http://www.mozilla.com/en-US/firefox/features.html
Comment 9•17 years ago
|
||
alternatively, instead of a query string, we could add a new attributes, fullDetailsURL to updates.xml (and AUS), and fix the client to use that. we could make the client robust so that if the fullDetailsURL attribute not set, it will fall back gracefully. this means more work for AUS (and the client side), but less work for the website.
Comment 10•17 years ago
|
||
jay points out another option. we have the following default pref: app.update.url.details. for fx 2 defaults to: http://%LOCALE%.www.mozilla.com/%LOCALE%/%APP%/releases/ for a major update, we could make the details links use that pref, and not the defaultURL attribute. (note this pref is default for minor updates, if the detailsURL was not specified.) or, we could define a new pref and default it to: http://%LOCALE%.www.mozilla.com/%LOCALE%/%APP%/features.html, and that could redirect to the proper page as listed on http://wiki.mozilla.org/Firefox2/Major_Update_Web_Content#Content. note, that still requires work from our website to handle all these redirects.
Version: 2.0 Branch → 1.5.0.x Branch
Comment 11•17 years ago
|
||
Adding Reed, Wil and Jeremy for an opinion on handling redirects.
Comment 12•17 years ago
|
||
A redirect would be possible, but if we're going through the trouble to change the query string anyway, I think adding another attribute or using the default pref in comment #10 seems like the cleanest way to do this.
Comment 13•17 years ago
|
||
After talking to pkim, this is not a blocker for major update, but it will be nice to get this in for 1.5.0.10/2.0.0.2, so let's try to get a patch together quickly. Who can whip one up in the next couple of days? Code freeze is scheduled for tomorrow 1/25, so it'll be nice to get it in for the upcoming releases (so future updaters get better content).
Flags: wanted1.8.1.x+
Flags: wanted1.8.0.x+
Comment 14•17 years ago
|
||
This is still present in the current (new) Major Update Testing.
Comment 15•17 years ago
|
||
We need an owner for this if we want to try to fix this for major update (scheduled to go out in a few weeks, hopefully). Will the redirect approach only need server side and/or build config changes? If it requires code changes to Firefox, we will probably have to push this out to 2.0.0.5. Who can own this? Wil?
Comment 16•17 years ago
|
||
What is broken? I'm sorry, it's been 4 months since I looked at this, and I can't really follow this thread. Can you restate: - expected behavior - actual behavior
Comment 17•17 years ago
|
||
The problem is, I think, that the update.rdf contains only a single details link, and that URL is used both for the embedded content in the update offer dialog and as the target of a "more details" link. If you click on the "more details" link you get a very empty, sparse page, because the content is sized to fit into a little embedded frame. There are two possible fixes that come to mind - have two different URLs in the update.rdf, one for the embedded content, and one that goes directly to the "learn more" link you can see in the screen shot. - In the major update case suppress the "Details" link and assume the user saw the embedded content. Or, just live with it, as not many people are going to select apply later, then manually start it, and then want to hit the details link. For the small number of people doing that maybe we just live with an emptyish page, and they can click on the "learn more" link to get to the real info.
Flags: blocking-firefox3?
Comment 18•17 years ago
|
||
So we should definitely live with it for 1.5 -> 2.0, but I think we should make it better for the 2.0 -> 3.0 upgrade. That means fixing it in some future 1.8.1.x release (the sooner the better)
Flags: blocking1.8.1.5?
Updated•17 years ago
|
Flags: wanted1.8.0.x+ → wanted1.8.0.x-
Comment 19•17 years ago
|
||
Blocking for Firefox 3; in the meantime, though, isn't there anything we can do server-side to detect the referrer ID such that we can detect when you're coming from the link? Or am I merely dreaming?
Flags: blocking-firefox3? → blocking-firefox3+
Comment 21•17 years ago
|
||
When this is fixed in FF3 we'll want to take the change in a FF2 build so it helps major updates to 3, but until there's a fix it's not blocking any specific 2.0.0.x release.
Flags: blocking1.8.1.5?
Reporter | ||
Comment 22•17 years ago
|
||
When updating today, I noticed the "Details" link on the trunk updates leads to http://www.mozilla.org/projects/firefox/, which is a page that is also out of date.
Comment 23•17 years ago
|
||
(In reply to comment #22) > When updating today, I noticed the "Details" link on the trunk updates leads to > http://www.mozilla.org/projects/firefox/, which is a page that is also out of > date. Nightly updates work a bit differently to release ones, because detailsURL is not specified in the update.xml. The app then falls back to http://mxr.mozilla.org/seamonkey/source/browser/branding/unofficial/pref/firefox-branding.js#8 For completeness, Firefox 2 release builds fall back to http://mxr.mozilla.org/mozilla1.8/source/other-licenses/branding/firefox/pref/firefox-branding.js#8
Updated•17 years ago
|
Assignee: nobody → sspitzer
Target Milestone: Firefox 3 M7 → Firefox 3 M9
Updated•17 years ago
|
Target Milestone: Firefox 3 M9 → Firefox 3 M10
Updated•17 years ago
|
Target Milestone: Firefox 3 M10 → Firefox 3 M11
Updated•17 years ago
|
Priority: -- → P5
Updated•17 years ago
|
Flags: wanted-firefox3+
Flags: blocking-firefox3-
Flags: blocking-firefox3+
Target Milestone: Firefox 3 Mx → Firefox 3 M11
Assignee | ||
Updated•16 years ago
|
Product: Firefox → Toolkit
Comment 24•16 years ago
|
||
This polish shouldn't block bug 412372
Assignee: moco → nobody
No longer blocks: 412372
Comment 26•15 years ago
|
||
I think the best way to fix this is by fixing bug 475671
Depends on: 475671
Comment 28•14 years ago
|
||
I'm fixing this in bug 530872 but I am tracking the fix as 475671 so resolving duplicate of bug 475671.
You need to log in
before you can comment on or make changes to this bug.
Description
•