405257 - gUpdates.wiz is null in some cases

Status: RESOLVED FIXED

(Toolkit :: Application Update, defect)

Description

[Reed Loden [:reed]]

After selecting Help --> Check for Updates..., I get the following error in the Error Console:

Error: gUpdates.wiz is null
Source File: chrome://mozapps/content/update/updates.js
Line: 863

863    gUpdates.wiz.getButton("next").disabled = !licenseAccepted;

Looking at toolkit/mozapps/update/content/updates.js, there seems to be a disagreement on what things use |gUpdates.wiz| versus |this.wiz|. Maybe that's the problem?

Comment 1

[(not reading, please use [e-mail] instead)]

I can reproduce the error, but I'm not seeing any "user facing" problems because of it, so I'm not sure if this is blocking.

Comment 3

[Serge Gautherie (:sgautherie)]

(In reply to comment #0)
> Looking at toolkit/mozapps/update/content/updates.js, there seems to be a
> disagreement on what things use |gUpdates.wiz| versus |this.wiz|. Maybe that's
> the problem?

Right !

Definition:
[
 103 /**
 104  * A set of shared data and control functions for the wizard as a whole.
 105  */
 106 var gUpdates = {
 ...
 123   /**
 124    * The <wizard> element
 125    */
 126   wiz: null,
]

Initialization:
[
 316   /**
 317    * Called when the wizard UI is loaded.
 318    */
 319   onLoad: function() {
 320     this.wiz = document.documentElement;
]

32 |gUpdates| usages:
<http://mxr.mozilla.org/seamonkey/search?string=gUpdates.wiz&find=%2Ftoolkit%2Fmozapps%2Fupdate%2Fcontent%2Fupdates%5C.&tree=seamonkey>
14 |this| usages:
<http://mxr.mozilla.org/seamonkey/search?string=this.wiz&find=%2Ftoolkit%2Fmozapps%2Fupdate%2Fcontent%2Fupdates%5C.&tree=seamonkey>

Shall I s/this.wiz/gUpdates.wiz/g ?
|*.update|, |*.strings|, |*.brandName|, |this._setButton()|, ..., have the same "issue" !

Comment 4

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b3pre) Gecko/2008012102 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

These |wiz| declaration and initialization were added in "1.35	ben%bengoodger.com	2005-06-26 15:33".

While the use of either/both |this.| and |gUpdates.| seems unnecessarily confusing,
adding, in JS.D., a breakpoint at lines 320 and 862 reveals that the use (862) happens *before* the initialization (320) :-(

I don't know how to fix _that_ (first): helpwanted.

Comment 6

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

This also breaks updates for localized builds like Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9b5pre) Gecko/2008030405 Minefield/3.0b5pre

Comment 7

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

(In reply to comment #6)
> This also breaks updates for localized builds like Mozilla/5.0 (Windows; U;
> Windows NT 5.1; de; rv:1.9b5pre) Gecko/2008030405 Minefield/3.0b5pre

How so ? Updates for localised builds aren't set up.

Comment 8

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Oh, good to know. Sorry for the bugspam.

Comment 9

[Adrian Heine]

Reappeared in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a1pre) Gecko/2008061803 Minefield/3.1a1pre when clicking on 'Check for updates ...':

* "gUpdates.wiz is null" in updates.js (line 862)

Comment 10

[Robert Strong (they/them - no direct email)]

Attachment: patch rev1

This works around this bug for me. As the comment in the patch states:

   onAcceptDeclineRadio: function() {
+    // Return early if this page hasn't been loaded (bug 405257). This event is
+    // fired during the construction of the wizard before gUpdates has received
+    // its onload event.
+    if (!this._licenseContent)
+      return;
+

Comment 11

[Dave Townsend [:mossop]]

Comment on attachment 335682 [details] [diff] [review]
patch rev1

I'll say ok to this, though I've filed bug 452389, I think we should be fixing the radiogroup widget to not send select at all in this case, in which case we could back this out.

Comment 12

[Robert Strong (they/them - no direct email)]

(In reply to comment #11)
> (From update of attachment 335682 [details] [diff] [review])
> I'll say ok to this, though I've filed bug 452389, I think we should be fixing
> the radiogroup widget to not send select at all in this case, in which case we
> could back this out.
Agreed... this error has been blamed when trying to diagnose other bugs otherwise I'd leave it. Thanks for filing bug 452389 and the review.

Comment 13

[Robert Strong (they/them - no direct email)]

Pushed to mozilla-central
http://hg.mozilla.org/mozilla-central/index.cgi/rev/54a3bd4d8b4716942deef61c7a8092cde5126b50

Comment 14

[Robert Strong (they/them - no direct email)]

Comment on attachment 335682 [details] [diff] [review]
patch rev1

Drivers, when a user has a problem updating they often blame it on this error in the error console. I'd like to get this for 1.9.0.3 since it is a simple fix and it will improve error reporting / reduce confusion when app update has problems.

Comment 15

[Daniel Veditz [:dveditz]]

Comment on attachment 335682 [details] [diff] [review]
patch rev1

Approved for 1.9.0.4, a=dveditz for release-drivers

Comment 16

[Robert Strong (they/them - no direct email)]

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

Comment 17

[Al Billings [:abillings - ex-MoCo]]

I don't see this error in the console when I check for updates on 3.0.3 on either OS X or Windows XP. Does this show up reliably as an error?

Comment 18

[Robert Strong (they/them - no direct email)]

After setting javascript.options.showInConsole to true in about:config I see the error.

Comment 19

[Al Billings [:abillings - ex-MoCo]]

Thanks, Rob. I didn't realize you had to set that option.

I've verified the fix in 1.9.0.4 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.4pre) Gecko/2008102404 GranParadiso/3.0.4pre.