Closed
Bug 120060
Opened 23 years ago
Closed 23 years ago
javascript build pop up window not displayed correctly
Categories
(Core :: Preferences: Backend, defect)
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
Comment 1•23 years ago
|
||
worksforme, linux build 2002-01-07-06. Click on the book to open the submenus and off you go...
Comment 2•23 years ago
|
||
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
Comment 3•23 years ago
|
||
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
Comment 4•23 years ago
|
||
Works for me, build 2002011103 on Windows ME. It may take a couple seconds for it to load (slow conn, slow computer, etc).
Reporter | ||
Comment 5•23 years ago
|
||
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]
Comment 6•23 years ago
|
||
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.
Comment 7•23 years ago
|
||
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?
Reporter | ||
Comment 8•23 years ago
|
||
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)
Comment 9•23 years ago
|
||
> 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?
Reporter | ||
Comment 10•23 years ago
|
||
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.
Comment 11•23 years ago
|
||
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
Assignee | ||
Comment 12•23 years ago
|
||
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
Comment 13•23 years ago
|
||
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.
Comment 14•22 years ago
|
||
*** Bug 141979 has been marked as a duplicate of this bug. ***
Comment 15•22 years ago
|
||
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.
Description
•