Closed Bug 405257 Opened 17 years ago Closed 16 years ago

gUpdates.wiz is null in some cases

Categories

(Toolkit :: Application Update, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: reed, Assigned: robert.strong.bugs)

References

(Depends on 1 open bug)

Details

(Keywords: verified1.9.0.4)

Attachments

(1 file)

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?
Flags: blocking-firefox3?
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.
Flags: blocking-firefox3? → blocking-firefox3-
(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" !
[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.
Keywords: helpwanted
Keywords: helpwantedqawanted
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
(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.

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)
Flags: wanted-firefox3.1?
Product: Firefox → Toolkit
Attached patch patch rev1Splinter Review
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;
+
Assignee: nobody → robert.bugzilla
Status: NEW → ASSIGNED
Attachment #335682 - Flags: review?(dtownsend)
Depends on: 452389
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.
Attachment #335682 - Flags: review?(dtownsend) → review+
(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.
Pushed to mozilla-central
http://hg.mozilla.org/mozilla-central/index.cgi/rev/54a3bd4d8b4716942deef61c7a8092cde5126b50
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Flags: wanted1.9.1?
Keywords: qawanted
Attachment #335682 - Flags: approval1.9.0.3?
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 on attachment 335682 [details] [diff] [review]
patch rev1

Approved for 1.9.0.4, a=dveditz for release-drivers
Attachment #335682 - Flags: approval1.9.0.4? → approval1.9.0.4+
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
Keywords: fixed1.9.0.4
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?
After setting javascript.options.showInConsole to true in about:config I see the error.
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.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: