276008 - Help contents all disappeared in this build

Status: RESOLVED FIXED

(SeaMonkey :: Help Viewer, defect)

Description

[Riven Cui]

USER-AGENT:Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6)
Gecko/20041223 Firefox/1.0+

The help viewer doesn't contain anything, except the frame and some toolbar buttons.

Comment 1

[Riven Cui]

Attachment: Help contents disappear

Comment 2

[:Gavin Sharp [email: [e-mail]]]

Regressed between the 2004-12-22 and 2004-12-23 builds.

Comment 3

[:Gavin Sharp [email: [e-mail]]]

Which would be
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-12-22&maxdate=2004-12-24&cvsroot=%2Fcvsroot

I fail to see any checkins that could have had any effect.

Comment 4

[:Gavin Sharp [email: [e-mail]]]

Taking firefox.exe, nspr4.dll, and js3250.dll from the old build (12-22) and
putting in a  new (12-24) build solves the problem. The only changed file is
js3250.dll, but the other two need to be changed as well since they depend on it.

So basically, the changed code seems to be in whatever compiles to js3250.dll,
and changing the front end files (\chrome\) has no effect.

The only checkins in that window that are JS related (which I'm assuming is what
js3250.dll is about) are bug 275742 or bug 246441, and both are r=shaver. Bug
275742 seems most likely, but this stuff is completely out of my league.

Also, I'm hoping that I didn't make some stupid mistake in testing this.
Verification/correction of these findings/assumptions would be appreciated/welcomed.

Comment 5

[:Gavin Sharp [email: [e-mail]]]

The errors given in the JS console when trying to view help are the following:

Redeclaration of function XML
in help.js at line 13
(const XML = "http://www.w3.org/XML/1998/namespace#")

and

init is not defined
in help.xul at line 1

Comment 6

[Riven Cui]

(In reply to comment #4)
> Taking firefox.exe, nspr4.dll, and js3250.dll from the old build (12-22) and
> putting in a  new (12-24) build solves the problem. The only changed file is
> js3250.dll, but the other two need to be changed as well since they depend on it.

I replaced nspr4.dll (version 4.0.0.0) from mozilla build 2004121706 £¬and
js3250.dll from thunderbird 1.0, then it works ok again.

Comment 7

[Steffen Wilberg]

Seamonkey is affected as well. The js error mentioned in comment 5 is the key
here. I don't understand it, since XML is neither a function, nor is it
redeclared. It looks like it's now reserved.

Changing "const XML" to "var XML" fixes this. But since the XML and SD consts
are not in use, I guess these two lines should be removed:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/toolkit/components/help/content/help.js&rev=1.17&root=/cvsroot&mark=52-53#40
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/extensions/help/resources/content/help.js&rev=1.63&root=/cvsroot&mark=55-56#42

Comment 8

[[e-mail]]

(In reply to comment #7)
>Seamonkey is affected as well. The js error mentioned in comment 5 is the key
>here. I don't understand it, since XML is neither a function, nor is it
>redeclared. It looks like it's now reserved.
It looks like it is now a function as part of E4X e.g. XML("<foo/>")

>But since the XML and SD consts are not in use
I assume you mean SN here, rathere than SD?

>I guess these two lines should be removed:
rs=me on the removal of the unused constants. They were badly named anyway.

Comment 9

[Brendan Eich [:brendan]]

Gah.  I'll take some blame here, as E4X support was not supposed to be enabled
for web page scrip yet.  Two issues:

1.  Should the JS engine eagerly or lazily initialize the XML class constructor,
and any other E4X stuff, without JS_SetOptions(cx, ... | JSOPTION_XML)?  I say no.

2.  Should the DOM lazy standard class init code punt on resolving not only if
(as it does now) JSRESOLVE_ASSIGNING, but also if JSRESOLVE_DECLARING?  Cc'ing jst.

/be

Comment 10

[Steffen Wilberg]

SN indeed.

Comment 11

[Steffen Wilberg]

Fixed by removing the unused constants.

Checking in mozilla/toolkit/components/help/content/help.js;
/cvsroot/mozilla/toolkit/components/help/content/help.js,v  <--  help.js
new revision: 1.18; previous revision: 1.17
done
Checking in mozilla/extensions/help/resources/content/help.js;
/cvsroot/mozilla/extensions/help/resources/content/help.js,v  <--  help.js
new revision: 1.64; previous revision: 1.63
done

Comment 12

[Brendan Eich [:brendan]]

Re: comment 9 issue 1: unfortunately (or not, API's simpler this way), we can't
cause XML and other E4X global object properties to appear and disappear with
JS_SetOptions calls, because that API is infallible.  It's better to have XML
there when requested.

So the only tractable issue is #2: the JS engine (and the DOM, but I shouldn't
have singled out the DOM in this issue) could avoid resolving a class
constructor when processing a declaration of that class's name.

Oops, this bug is closed.  I'll take my monologue to a JS engine bug.  Thanks,

/be

Comment 13

[Benjamin Smedberg]

Several other bugs are marked in-testsuite? that will cover this problem.