Closed
Bug 296212
Opened 19 years ago
Closed 19 years ago
For pages that are just name=value&name2=value2& the last ampersand is dropped.
Categories
(Core :: DOM: HTML Parser, defect)
Tracking
()
VERIFIED
FIXED
People
(Reporter: say_ten, Assigned: mrbkap)
References
()
Details
(Keywords: testcase)
Attachments
(2 files)
2.77 KB,
patch
|
jst
:
review+
bzbarsky
:
superreview+
chofmann
:
approval1.8b3+
|
Details | Diff | Splinter Review |
43 bytes,
text/html
|
Details |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Look at the URL in Mozilla and IE. You can see that IE renders the final ampersand whereas Mozilla looses it. I know it's not much of a HTML page but I was writing a page that outputted data in this format but couldn't see a error in the loop because of the missing &. Not a biggy but I'm unaware of any consequences this may have. Reproducible: Always Steps to Reproduce:
Comment 1•19 years ago
|
||
Ampersands cannot appear by themselves in HTML, they start a character reference. If you want to encode an ampersand in HTML, you need to use |&| instead of just |&| As for this bug, it's technically invalid, but leaving open in case the parser folks want to do anything about this edge case.
Assignee | ||
Comment 2•19 years ago
|
||
Yeah, this is an edge case we should handle properly -- especially considering the final ampersand doesn't show up in view source.
Assignee: parser → mrbkap
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Updated•19 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 3•19 years ago
|
||
This simply consumes the last & in the file as text. The Peek() is checking the 2nd character after the current one. Note the migration away from mIsFinalChunk because it is insufficient in the face of document.write(), where we can have mIsFinalChunk = PR_TRUE, but aScanner.IsIncremental() = PR_TRUE.
Assignee | ||
Updated•19 years ago
|
Attachment #185039 -
Flags: superreview?(bzbarsky)
Attachment #185039 -
Flags: review?(jst)
Updated•19 years ago
|
Attachment #185039 -
Flags: superreview?(bzbarsky) → superreview+
Comment 4•19 years ago
|
||
Comment on attachment 185039 [details] [diff] [review] patch v1 r=jst
Attachment #185039 -
Flags: review?(jst) → review+
Assignee | ||
Comment 5•19 years ago
|
||
Comment on attachment 185039 [details] [diff] [review] patch v1 This safe patch makes the parser not lose data, and makes view source not lie so much.
Attachment #185039 -
Flags: approval1.8b3?
Comment 6•19 years ago
|
||
Comment on attachment 185039 [details] [diff] [review] patch v1 a=chofmann
Attachment #185039 -
Flags: approval1.8b3? → approval1.8b3+
Assignee | ||
Comment 7•19 years ago
|
||
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Comment 8•19 years ago
|
||
The final ampersand is indeed rendered when viewing the following URL http://www.sayten.34sp.com/moztests/dropping_ampersands.html in today's 2005-06-03-06 Windows XP Seamonkey trunk build. Output is as follows: db_pass=tpa&db_server=beastie4&db_user=tpa& (The final ampersand shows up in view source as well in bolded orange.) Verified FIXED
Status: RESOLVED → VERIFIED
Assignee | ||
Comment 9•19 years ago
|
||
Attaching the testcase for future reference.
You need to log in
before you can comment on or make changes to this bug.
Description
•