Closed Bug 367913 Opened 14 years ago Closed 11 years ago
"Details" link in software update dialog leads to meaningless page
Seen while testing the upgrade path from 188.8.131.52->184.108.40.206 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.
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
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.)
This is the page that you get when you click on the Details link.
confirmed. I see the same on the major update testing. See the screenshot, i clicked on this details link.
Yes, those were my steps to reproduce. For a minor update, such as going from 220.127.116.11->18.104.22.168, that Details link points to http://www.mozilla.com/en-US/firefox/releases/22.214.171.124.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.) >
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
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.
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
Adding Reed, Wil and Jeremy for an opinion on handling redirects.
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.
After talking to pkim, this is not a blocker for major update, but it will be nice to get this in for 126.96.36.199/188.8.131.52, 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).
This is still present in the current (new) Major Update Testing.
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 184.108.40.206. Who can own this? Wil?
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
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.
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)
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+
Seth, another one for later.
Target Milestone: --- → Firefox 3 beta1
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.
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.
(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
Assignee: nobody → sspitzer
Target Milestone: Firefox 3 M7 → Firefox 3 M9
Target Milestone: Firefox 3 Mx → Firefox 3 M11
bah, wrong bug
I'm fixing this in bug 530872 but I am tracking the fix as 475671 so resolving duplicate of bug 475671.
Status: NEW → RESOLVED
Closed: 11 years ago
No longer depends on: 475671
Resolution: --- → DUPLICATE
Duplicate of bug: 475671
You need to log in before you can comment on or make changes to this bug.