unescape() function seems to fail if there's extended characters in the escaped information




Preferences: Backend
16 years ago
16 years ago


(Reporter: Scott van Looy, Assigned: Brian Nesse (gone))


Windows 2000

Firefox Tracking Flags

(Not tracked)





16 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1)
BuildID:    2002041711

This occurs in Netscape 6 and Mozilla RC1
I'm escaping an error message and reading it in through a querystring - works
fine if there's no extended characters, displays nothing if there are extended
characters...pretty sure that if I'm feeding it the data it should work (it's
fine in all other browsers I've tested in) - if it's not the way it should work
then it should probably not cause an exception at least

Reproducible: Always
Steps to Reproduce:
1.Visit above URL

Actual Results:  Error: uncaught exception: [Exception... "Component returned
failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIDOMWindowInternal.unescape]"
 nsresult: "0x8000ffff (NS_ERROR_UNEXPECTED)"  location: "JS frame ::
:: Display :: line 17"  data: no]

Expected Results:  Should display text as it does in Netscape 4.7
Ever confirmed: true

Comment 1

16 years ago
Reassigning to DOM Level 0

I can't confirm this with Mozilla trunk build 2002042808 WinNT.
When I load the given site, I see the same thing in Mozilla as
in NN4.7 and IE6:

              Sie konnten Ihr richtig ausfüllen nicht::
              - Check Box Bitte tragen Sie wieder ein
              und legen Sie wieder ein!

Am I missing something? What are the extended characters?
Can you give the Unicode values of a few of them? Thanks -
Assignee: rogerl → jst
Component: JavaScript Engine → DOM Level 0
QA Contact: pschwartau → desale

Comment 2

16 years ago
Scott reports:

> What you've seen appears to be right - however in my version of
> Mozilla I don't get that text I just get a blank box and the exception,
> same with Netscape 6 - it works fine if there are no special characters 
> (e.g. $aumlaut;) but doesn't appear to work if there are

Comment 3

16 years ago
Character "u" with an umlaut has the Unicode value 00FC (= 252 decimal).
See the Latin-1 Supplement chart at http://www.unicode.org/charts/ 

Note: I found bug 44272,
"javascript escape and unescape don't work properly with unicode chars"

Also note bug 107524,
"URL-encoding of "javascript:" URLs inconsistent"

What puzzles me here is that the given URL works just fine for me
using Mozilla trunk binaries 20020428xx on WinNT, Linux, and Mac -

Scott, could you try the URL again with an up-to-date build;
do you still have the error?

Also - try it with a new Mozilla profile:

       [(path to Mozilla)]./mozilla -profilemanager

Does the URL work with a new profile?

Comment 4

16 years ago
I suppose this bug centers on this part of the given URL:

should be unescaped to   

This is happening correctly for me in current Mozilla builds.

Comment 5

16 years ago
I have tried it at home and it all works fine and I see the text no problem in
the same version of Mozilla - I'm not going to be able to check with a new
profile in the problem version until Tuesday however as it's a long weekend here
- I'll do so on Tuesday and let you know though

Comment 6

16 years ago
I've just tried it with a new profile and it works fine! In which case, any idea
what the problem is? (and how I can fix it in my current profile :)


Comment 7

16 years ago
Scott: thanks. Reassigning this to Prefs:Backend component based 
on your findings. Would it be possible for you to compare the 
good profile vs. the bad profile by looking at the settings you see
in Mozilla's Edit > Preferences, and also View > Character Coding?

To compare profiles in detail, you'll have to diff the "prefs.js"
files for each profile, if you know how to do that. 

See bug 120060. In that bug, the user got the same error as you did
"(NS_ERROR_UNEXPECTED) nsIDOMWindowInternal.unescape]", until he
created a new profile. Comment number 11 in that bug is important:

See also bug 118404. There, we found the exact line in prefs.js
that was causing the problem there; see comment number 73 and following:

Finally, there is the meta bug 123027, "Verifier for prefs.js"
That will help us detect this type of problem in the future -
Assignee: jst → bnesse
Component: DOM Level 0 → Preferences: Backend
QA Contact: desale → rvelasco

Comment 8

16 years ago
Resolving this one as a duplicate of bug 120060, since
the symptoms and cause are the same in each case -

*** This bug has been marked as a duplicate of 120060 ***
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.