Um.... sounds like just a syntax error in the JS to me. We can evangelize. :)
Not sure of correct component to decide this; but not JS Engine. Reassigning to Parser for consideration - is it this component which decides what to do with %20 ?
Assignee: rogerl → harishd
QA Contact: pschwartau → moied
Phil: This has nothing to do with the parser. Giving bug to layout.
Assignee: harishd → attinasi
Component: Parser → Layout
QA Contact: moied → petersen
Moving Mozilla 1.01 bugs to 'future' milestone with priority P1 I will be pulling bugs from 'future' milestones when scheduling later work.
Priority: -- → P1
Target Milestone: mozilla1.0.1 → Future
*** Bug 130035 has been marked as a duplicate of this bug. ***
Keywords: mozilla1.0, nsbeta1
Assignee: attinasi → rogerl
QA Contact: petersen → pschwartau
Target Milestone: Future → ---
Assignee: rogerl → new-network-bugs
QA Contact: pschwartau → benc
+helpwanted As I understand it, each URL scheme is responsible for parsing their URI. Bringing some URL authority...
Created attachment 74596 [details] [diff] [review] patch to unescape the script With this patch the script gets unescaped before getting evaluated. Evaluation still returns an error ...
i think you want: NS_UnescapeURL(script); instead. otherwise, script.Length() might be incorrect.
andreas: do you want to own this bug?
Created attachment 74768 [details] [diff] [review] patch with darins fix ... and suddenly the submissions seems to work, thanks darin! All others: please try the fix ...
Attachment #74596 - Attachment is obsolete: true
Target Milestone: --- → mozilla1.0
Patch works great. :)
Assignee: new-network-bugs → andreas.otte
Comment on attachment 74768 [details] [diff] [review] patch with darins fix sr=darin
Attachment #74768 - Flags: superreview+
Anyone want to give an r=?
It is purely a URL parsing problem. If the JS Engine gets a valid program, it runs it correctly; nothing here indicates otherwise -
jst, this is a networking problem under dom. Want to give r=?
Comment on attachment 74768 [details] [diff] [review] patch with darins fix r=jst
Attachment #74768 - Flags: review+
Comment on attachment 74768 [details] [diff] [review] patch with darins fix a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #74768 - Flags: approval+
fix checked in
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
*** Bug 107524 has been marked as a duplicate of this bug. ***
FYI, this fix was not quite right, it introduced bug 144429, and it doesn't do the right thing with non ASCII characters.
Do we want to mark this fixed and then get a new bug for the second-layer of escaping problems?
Well, I think #2 is the only option. The RFC's pretty much say that you encode.
Yes, RFC 2396 pretty much defines the standard for all uris. That includes the allowed characters and the special meaning of %. The only option I see too is to encode it properly, for example if you want to send an already encoded string then you have to double encode it to get the right result after unescaping.
VERIFIED: mozilla 1.1b, netscape 7.0. I've got a brief testcase that has some escaped characters and it seems to work correctly.
Status: RESOLVED → VERIFIED
*** Bug 144429 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.