305226 - Details link in Software Update is broken.

Status: RESOLVED FIXED

(Toolkit :: Application Update, defect)

Description

[David B. Haun]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050819 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050819 Firefox/1.0+

The details link in the new software update system is broken if you click it you
get a blank browser page.

Reproducible: Always

Steps to Reproduce:
1.Choose Help menu.
2.Click Software Updates
3.Click Ok on the certifate error message.
4.Click the details link.

Actual Results:  
Blank browser page

Expected Results:  
Bring up a page about the software update and what it fixes.

Comment 1

[u63580]

Is this bug 301321 ?

Comment 2

[Adam Guthrie]

Please provide a URL for the page.

Comment 3

[David B. Haun]

No Url is dislayed so not avaiable for this bug.

Comment 4

[Michael Stolovitzsky]

Confirmed behaviour on Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1)
Gecko/20050828 Firefox/1.6a1: the "Details" link in the download dialog of
software update opens a window with a blank page

Comment 5

[Michael Stolovitzsky]

> Is this bug 301321 ?

No.

Comment 6

[Aaron Slunt]

Confirming Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4)
Gecko/20050827 Firefox/1.0+ ID:2005082715

What's 1.8b4 without this :)

Comment 7

[Scott MacGregor]

I don't think this is really a bug. We haven't had an official product update,
where the update service sends back a url which links to more information about
the update yet. This probably won't happen until we do a beta to beta or a beta
to RC type upgrade (if then).

Suggest an invalid resolution (at least until our website actually has a product
update page to send back via software update).

Comment 8

[Chase Phillips]

(In reply to comment #7)
> I don't think this is really a bug. We haven't had an official product update,
> where the update service sends back a url which links to more information about
> the update yet. This probably won't happen until we do a beta to beta or a beta
> to RC type upgrade (if then).

I'm not sure this is accurate.  There is no facility in the XML data sent from
AUS to the client to allow for this details link url (if that's what you're
referring to).  If there is, please let us know asap. :)

Comment 9

[Mike Schroepfer]

Ben - can you roll this up with all the other update-releated url fixes?

Comment 10

[Ben Goodger (use ben at mozilla dot org for email)]

Attachment: patch for 1.5b1

Scott said he was OK with the proposed website structure and documentation
organization I outlined here: http://wiki.mozilla.org/Web_Site_Updates 

So here is a patch for Firefox and Thunderbird for beta1 that simply makes the
manual link point at the release notes page, which has information on
downloading, installing, etc.

Comment 11

[Scott MacGregor]

Comment on attachment 194375 [details] [diff] [review]
patch for 1.5b1

looks good to me.

note: we'll probably need the fix for Bug 303941 9at least for Thunderbird) for
the details link to actually work when it gets clicked on.

Comment 12

[Daniel C]

Shouldn't these be 1.4 and no 1.3 in-line with bug 304470 and bug 304473? I
thought 1.5 Beta 1 was version number 1.4?

Comment 13

[Darin Fisher]

Yeah, I also believe that 1.3 should be changed to 1.4.  If time permits, it'd
probably make sense to modify the code to append the current application version
to this string so that we don't have to remember to update this preference when
we bump the application version number in the future.

Comment 14

[Jo Hermans]

*** Bug 306705 has been marked as a duplicate of this bug. ***

Comment 15

[Ben Goodger (use ben at mozilla dot org for email)]

Wait, back when we had 1 beta, it was 1.4. But now we have two betas. So what
will beta2 be called?

Comment 16

[Scott MacGregor]

(In reply to comment #15)
> Wait, back when we had 1 beta, it was 1.4. But now we have two betas. So what
> will beta2 be called?

1.4.1 is what I was told we'd be using for beta 2.

Comment 17

[Ben Goodger (use ben at mozilla dot org for email)]

Attachment: updated patch for b1

bringing forward reviews and approvals

Comment 18

[Ben Goodger (use ben at mozilla dot org for email)]

OK, scott tried this in tbird and I in firefox and it works, so good enough for b1. 

Comment 19

[Ben Goodger (use ben at mozilla dot org for email)]

Landed on the 1.8 branch for 1.8b4. Setting 1.8b5+ and clearing 1.8b4 flag for a
better long term solution in b2. 

Comment 20

[Magnus Melin [:mkmelin]]

This isn't working for me, not in thunderbird either...
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050907 Firefox/1.4

Comment 21

[Wayne Mery (:wsmwk)]

(In reply to comment #20)
> This isn't working for me, not in thunderbird either...

(Ditto) regression?

Comment 22

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050916 
Firefox/1.4

Right now, when you click on the details link absolutely nothing happens 
(except that focus rects get drawn around the link text). No new windows pop 
up. I did a little digging and found that all of the update.xml files 
currently being sent by the update server are coming 
with 'detailsURL="undefined"'. 

Once I set the app.update.url.override pref to an update.xml file with a 
valid 'detailsURL' value (like 'detailsURL="http://www.mozilla.org"') then a 
new window opens properly (to the mozilla page) after clicking the link text.

The patch above fixes the link that gets displayed when a 
download/verification/application-of-patch error occurs only. It has no effect 
on the behavior of the initial "Details" link. IMHO I think that Scott is 
right: this isn't really a bug unless everyone thinks that the update server 
should be providing a 'detailsURL' value. If that is the case then it's a 
server problem... unless I'm missing something?

Comment 23

[Travis Chase]

*** Bug 306926 has been marked as a duplicate of this bug. ***

Comment 24

[Darin Fisher]

Ben: I agree with you.  This link needs to be defined server-side.

Comment 25

[Phil Ringnalda (:philor)]

*** Bug 309540 has been marked as a duplicate of this bug. ***

Comment 26

[Ben Goodger (use ben at mozilla dot org for email)]

I have a nice solution for this problem. What do you all think? 

We should make this link point to http://www.mozilla.org/ for Firefox and
Thunderbird, since this is the link that offers simple one-click update links to
the newest version of either application for the appropriate language+platform...

It also saves us a lot of documentation and server side burden for an unlikely
and more difficult to test condition.

Comment 27

[James Ross]

Arguably it should be http://www.mozilla.org/products/firefox/ and
http://www.mozilla.org/products/thunderbird/ or it'll be less clear what's going
on (and sidelining Thunderbird).

Comment 28

[Justin Dolske [:Dolske]]

(In reply to comment #26)
> I have a nice solution for this problem. What do you all think? 
> 
> We should make this link point to http://www.mozilla.org/

I think it needs to point to some place much more specific.

To me, as a user, "details" for an upgrade ought to explain what's new or
different with the version I'm getting. For a public release, this probably
ought to be the "What's New" section in the release notes. Dumping the user off
onto a generic Mozilla or product page isn't useful at all.

Nightly builds are a little more tricky, since no one is going to type up notes
for each build. Ideally there would be some kind of automagically generated
page, similar to The Burning Edge updates. Even a raw list of CVS commits might
work -- given the target audience. But if something like this isn't available,
the link probably just ought to be removed... If you can't send the user
someplace appropriate and useful, there's no point in the link.

It would be really spiffy to show a dynamic list of what's changed between "what
I've got" and "what I'm getting," but *anything* useful would be a good first step.

Comment 29

[Ben Goodger (use ben at mozilla dot org for email)]

I could settle for products/[firefox|thunderbird]/ for the reasons James states.
I understand why you'd want something specific in this case, you just need to
understand this case isn't that common, and it's difficult to get copy made and
maintained for each product describing each circumstance. 

At the most elaborate, I imagine the product pages having a piece of sniffer js
on them that operates much like that on caminobrowser.org that detects an old
product and has some sort of brightly colored box urging people to upgrade. But
I think just the product page is suitable for now. 

Comment 30

[Stebs]

(In reply to comment #28)

> Nightly builds are a little more tricky, since no one is going to type up notes
> for each build. Ideally there would be some kind of automagically generated
> page, similar to The Burning Edge updates. Even a raw list of CVS commits might
> work -- given the target audience. But if something like this isn't available,
> the link probably just ought to be removed...

For Nightly Branch and Trunk Builds, this Feed from Peter(6) would probably be
the most appropriate there is atm:
http://www.extensionsmirror.nl/peter6/firefoxfeed.xml
This Feed points to the last 7 Branch and Trunk Mozillazine Forum Threads and
the first Post of each Tread shows the Checkins for that Build. 

Comment 31

[Magnus Melin [:mkmelin]]

The feeds from Peter(6) would be nice... If not, then at least point the details
link to the release notes, not the product page. For nightly builds, linking to
the mozillazine official builds forums would also be fine by me.

Comment 32

[Ben Goodger (use ben at mozilla dot org for email)]

Attachment: final patch

Comment 33

[Scott MacGregor]

Ben can you get this checked in today along with adding the fixed1.8 keyword?
Thanks.

Comment 34

[Ben Goodger (use ben at mozilla dot org for email)]

Comment on attachment 197476 [details] [diff] [review]
final patch

approving for the branch

Comment 35

[Ben Goodger (use ben at mozilla dot org for email)]

Comment on attachment 197476 [details] [diff] [review]
final patch

approving for the branch

Comment 36

[Ben Goodger (use ben at mozilla dot org for email)]

landed on the trunk, too. 

Comment 37

[Magnus Melin [:mkmelin]]

This isn't working, just updated from 20050928 to 20050929.
Checked was 2005-09-27 16:15. So it should have been in 20050928, no?

Really can't see how the patch would have fixed it either, since it only changes
two existing urls. The problem - at least for me - was that the links do nothing
at all. 

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b5) Gecko/20050929 Firefox/1.4
ID:2005092905

Comment 38

[Tim Meader]

Actually, clicking on the link DID previously open a browser page (which was
blank as this bug describes). I agree though that clicking the link hasn't done
ANYTHING in at least a week or two... no blank bage and no new page at all.

Comment 39

[Ben Goodger (use ben at mozilla dot org for email)]

Crap, I had this bug confused with another. 

Comment 40

[Ben Goodger (use ben at mozilla dot org for email)]

Attachment: fix the details link too ;-)

Comment 41

[Ben Goodger (use ben at mozilla dot org for email)]

Adding late-l10n keyword.

Comment 42

[Darin Fisher]

Comment on attachment 197909 [details] [diff] [review]
fix the details link too ;-)

>Index: toolkit/mozapps/update/src/nsUpdateService.js.in
...
>   /**
>    * See nsIUpdateService.idl
>    */
>+  get detailsURL() {
>+    if (!this._detailsURL) {
>+      try {
>+        // Try using a default details URL supplied by the distribution
>+        // if the update XML does not supply one.
>+        return gPref.getComplexValue(PREF_APP_UPDATE_URL_DETAILS,
>+                                     nsIPrefLocalizedString).data;
>+      }
>+      catch (e) {
>+      }
>+    }
>+    return this._detailsURL;
>+  },

So, this returns null if getComplexValue fails.  Is that okay, or
should it return ""?

Needs tbird changes too, right?


r=darin

Comment 43

[Ben Goodger (use ben at mozilla dot org for email)]

Attachment: patch

return "" instead of null and add the tbird value.

Comment 44

[Ben Goodger (use ben at mozilla dot org for email)]

Comment on attachment 198006 [details] [diff] [review]
patch

requesting approval

Comment 45

[Scott MacGregor]

Comment on attachment 198006 [details] [diff] [review]
patch

thanks ben.

Comment 46

[Ben Goodger (use ben at mozilla dot org for email)]

Landed branch and trunk. 

Comment 47

[Asaf Romano (gone)]

fixed1.8 if so, and CCing firefoxl10n...

Comment 48

[Jesus Cea]

A link to
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=MOZILLA_1_8_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=day&cvsroot=%2Fcvsroot
would be satisfying too (for me :-).

A "decent" information page for each nightly update could be very nice, ever if
that page is fairly technical.

Comment 49

[Dave Miller [:justdave]]

(In reply to comment #48)
> A "decent" information page for each nightly update could be very nice, ever if
> that page is fairly technical.

You mean like this one?

http://www.squarefree.com/burningedge/

Comment 50

[Jesus Cea]

That could be very nice, Dave.

Adding that page to my daily bookmarks :).

Comment 51

[Adam Guthrie]

*** Bug 311134 has been marked as a duplicate of this bug. ***

Comment 52

[csalsa]

Still broken in beta 2.  Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.8b5) Gecko/20051004 Firefox/1.4.1

Comment 53

[Shaohua Wen]

It seems the changes in messenger-region/region.properties  is not checked in
for 1.8 branch.

Comment 54

[Dave Miller [:justdave]]

confirmed, this is still broken on the 10/04 builds on the 1.8 branch.

Comment 55

[Scott MacGregor]

if something is wrong with this patch we can address it for RC1

Comment 56

[Nick Thomas [:nthomas] (UTC+12)]

*** Bug 311199 has been marked as a duplicate of this bug. ***

Comment 57

[Jesse Ruderman]

*** Bug 311620 has been marked as a duplicate of this bug. ***

Comment 58

[Scott MacGregor]

I just checked in the missing change to messenger-region/region.properties (good
catch Shaohua Wen. That change was only missing on the branch. 

Comment 59

[Asaf Romano (gone)]

Comment 52 refers to Firefox, i'm pretty sure i've seen that too :-/

Comment 60

[Asaf Romano (gone)]

OK, the details link (while downloading an update) does nothing for me in

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b5) Gecko/20051013
Firefox/1.4.1

The "View more information" link works though (opens Beta 1's release notes).

Comment 61

[Asa Dotzler [:asa]]

Marcia and Tracy, can you look into this for us? Thanks.

Comment 62

[Marcia Knous [:marcia]]

Using Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b5)
Gecko/20051013 Firefox/1.4.1,  the details link takes me to:
http://www.mozilla.org/products/firefox/releases/1.5beta1.html - I think that is
the desired behavior.

As Mano notes in Comment 60, the  "View More Information" link works ok. 

Testing on a G5 using 10.4.2.

Comment 63

[Asaf Romano (gone)]

FWIW, i see the same issue in Thunderbird in a build from version 20051012.

Comment 64

[Adam Guthrie]

*** Bug 312585 has been marked as a duplicate of this bug. ***

Comment 65

[Asaf Romano (gone)]

Attachment: Fix the "Details" link in the "Donwloading..." page

Comment 66

[Asaf Romano (gone)]

As for the second issue, it seems
http://www.mozilla.org/products/firefox/releases/ still points to the release
notes of the first beta.

Comment 67

[Asaf Romano (gone)]

*weird*. Which icon (filename) is used in the start page? is it broken in other
places (read: about dialog)?

Comment 68

[Asaf Romano (gone)]

wrong bug, sorry for bugspam.

Comment 69

[Asa Dotzler [:asa]]

Comment on attachment 199785 [details] [diff] [review]
Fix the "Details" link in the "Donwloading..." page

Mike, can you review this so we can get it landed? Thanks.

Comment 70

[Asaf Romano (gone)]

Checking in toolkit/mozapps/update/content/updates.js;
/cvsroot/mozilla/toolkit/mozapps/update/content/updates.js,v  <--  updates.js
new revision: 1.52; previous revision: 1.51
done

Comment 71

[Asaf Romano (gone)]

1.8 branch:
Checking in updates.js;
/cvsroot/mozilla/toolkit/mozapps/update/content/updates.js,v  <--  updates.js
new revision: 1.45.2.5; previous revision: 1.45.2.4
done

Comment 72

[Magnus Melin [:mkmelin]]

*** Bug 315222 has been marked as a duplicate of this bug. ***