Closed Bug 120060 Opened 23 years ago Closed 23 years ago

javascript build pop up window not displayed correctly

Categories

(Core :: Preferences: Backend, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

()

VERIFIED WORKSFORME

People

(Reporter: rein, Assigned: bnesse)

References

()

Details

the above mentioned url raises a second window for navigation. This window is
built using javascripting and cookies. For whatever reason, since M 0.9.7 this
window remains almost empty and no navigation is possible anymore
worksforme, linux build 2002-01-07-06.  Click on the book to open the submenus
and off you go...
Reassigning to Browser-General until we can get further info.
Rein, what was the date of your Mozilla build? Please include 
that in any bug report.

Also, do you see any errors in Task | Tools | JavaScript Console?
(be sure to clear it out of any previous errors first)
Assignee: rogerl → asa
Component: Javascript Engine → Browser-General
QA Contact: pschwartau → doronr
Note: this site also WORKSFORME using Mozilla binaries 200201020xx
on WinNT, Linux, and Mac9.1. No errors in the JavaScript Console, 
except the benign, ubiquitous error occurring on every page load:

Error: redeclaration of const hide
Source File: chrome://wallet/content/walletOverlay.js
Line: 1
Works for me, build 2002011103 on Windows ME.
It may take a couple seconds for it to load (slow conn, slow computer, etc).
I am using build 2002011403 

Javascript console gives three errors when the window pops up:

Error: redeclaration of const hide
Source File: chrome://wallet/content/walletOverlay.js
Line: 1

Error: redeclaration of const hide
Source File: chrome://wallet/content/walletOverlay.js
Line: 1

Error: uncaught exception: [Exception... "Component returned failure code:
0x80500001 [nsIDOMWindowInternal.escape]"  nsresult: "0x80500001 (<unknown>)" 
location: "JS frame :: http://www.fwn.rug.nl/betaplus/roadmap.html ::
setCurrState :: line 110"  data: no]

Rein: thanks. The first two errors are not important - they occur on 
every page load. The third error points to this function:

// Record current settings in cookie
function setCurrState(setting)
{
  var expire = new Date();
  expire.setTime(expire.getTime() + ( 7*24*60*60*1000 ) ); // expire in 1 week
  document.cookie = "currIndex=" + escape(setting) + 
                    "; expires = " + expire.toGMTString();   
}



Rein: this probably doesn't have anything to do with it, but just in case: 
what is your setting in Edit > Preferences > Privacy & Security > Cookies?
Do you have "Enable all cookies" selected?

Also take a look at Edit > Preferences > Advanced > Scripts & Windows.
Are you allowing scripts to do everything? 

Finally, try making a new profile. To do this, you can run Mozilla
from a DOS command line as follows: 

cd (path to Mozilla)
./mozilla.exe -profilemanager

When the Profile Manager comes up, there's a button called "Create Profile".
I'm wondering if the problem goes away if you start using a new profile.
By using Tasks > Tools > JavaScript Debugger, I set a breakpoint in the 
setCurrState() function indicated in the error above. Here are some values
I got for the variable |setting|, and the expression |escape(setting)|:

typeof setting
$[0] = [string] "string"
setting
$[1] = [string] "000000000000000000000000000000000000000000000000000000000000"
setting.length
$[2] = [integer] 60
escape(setting) === setting
$[2] = [boolean] true


$[0] = [string] "100000000000000000000000000000000000000000000000000000000000"
setting.length
$[1] = [integer] 60
escape(setting) === setting
$[2] = [boolean] true


To get the function setCurrState() to fire, I had to wait until the
child navigation window came up and displayed its navigation tree.
I then toggled on the parent node of the tree. That fires the toggle()
function, which in turn fires setCurrState(). I never observed the 
setCurrState() function firing on page load alone.

Rein: when the child navigation window comes up, does it show the parent
node? If you use the JavaScript Console, can you see exactly when you get
that [nsIDOMWindowInternal.escape] error? Does it occur when you click on
the parent node?
The problem is solved, probably because of the fact that I did not had any
character code declared through edit/preferences/navigator/languages. When
setting this to Western ISO-8859-15 the problem was solved.
Is this because the cookies are written in a unreadable format when no character
coding is set???

To be complete and answer your questions:
- I have enable all cookies
- I have everything allowed in Advanced/Scripts & windows

The strang thing is that everything worked in older versions of Mozilla (before
0.9.7) and I can not remember to have ever changed the character coding, so this
must have been undefined in previous versions as well (or can it be changed when
going to a new version (or using Netscape 6.2 once in a while: N6.2 reads the
same preferences)
> The problem is solved, probably because of the fact that I did not have
> any character code declared through edit/preferences/navigator/languages.
> When setting this to Western ISO-8859-15 the problem was solved.

Rein: thanks! But I'm wondering, when you did not have any character code
declared, what did that look like in edit/preferences/navigator/languages? 
The selectbox at lower left, "Character Coding": was it blank?  
Or did it have a non-Western character coding selected? 
Phil: the button was empty.

I cannot remember nor recall how and what in previous versions of Mozilla
(before 0.9.7)
Can it be that, in the new javascript engine, some variable containing the
character coding is not initialized with some default value, while it was in
previous versions of Mozilla.
Or, can it be that, installing Netscape 6.x versions might disturbe the settings?

I cannot remember ever set the character coding, since I started to use Mozilla
after being a Netscape 4.x user. 

Reassigning to Preferences: Backend for further analysis. See the discussion 
beginning in Comment #8. Apparently Rein did not have any default setting
for Character Coding in edit/preferences/navigator/languages.

This would, I think, explaing the error reported in Comment #5:

Error: uncaught exception: [Exception... "Component returned failure code:
0x80500001 [nsIDOMWindowInternal.escape]"  nsresult: "0x80500001 (<unknown>)" 
location: "JS frame :: http://www.fwn.rug.nl/betaplus/roadmap.html ::
setCurrState :: line 110"  data: no]


The DOM escape() function would indeed error like this if no character coding 
had been defined...

Meanwhile, I cannot seem to delete my own character coding to null
in order to reproduce the bug. In my own "all.js" file, I found this:

//  Charset Mode
// ------------------
// 1 = doccharactersetBidi *
// 2 = defaultcharactersetBidi
pref("bidi.characterset", 1);


But I didn't find anything for character encoding. Thus I can't see
how to make mine null, to try and reproduce the conditions above -
Assignee: asa → bnesse
Component: Browser-General → Preferences: Backend
QA Contact: doronr → sairuh
While it is possible that the document may be confused by not having a valid
charset, there is no indication whatsoever that the preferences engine is at
fault for this. In fact, there are no calls to the preferences engine anywhere
near this code.

The most likely cause for this scenario is a corrupt user.js file or a change to
the mozilla environment. There were a number of bugs around the 0.9.7 timeframe
pertaining to XUL level changes that caused numerous issues with UI and menus
coming up empty or with no items selected.

Closing this bug as it is now WFM for everyone involved including the reporter.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Note: compare bug 118404:


------- Additional Comment #73 From Jason Johnston 2002-01-31 15:47 -------

I noticed that in attachment 63775 [details] there exists the line

            user_pref("intl.charset.default", ""); 

Note the empty string value.

I ran into some problems before when I had this line in my prefs.js - for
instance, the url of links would not show up in the status bar when I moused
over them, and occasionally external JS files would not load.  Deleting that
line cleared them up.... 
  
                               etc.
                               etc.
*** Bug 141979 has been marked as a duplicate of this bug. ***
mass-verifying WorksForMe bugs.

reopen only if this bug is still a problem with a *recent trunk build*.

mail search string for bugspam: AchilleaMillefolium
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.