Closed
Bug 296212
Opened 21 years ago
Closed 21 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•21 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•21 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•21 years ago
|
Status: NEW → ASSIGNED
| Assignee | ||
Comment 3•21 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•21 years ago
|
Attachment #185039 -
Flags: superreview?(bzbarsky)
Attachment #185039 -
Flags: review?(jst)
Updated•21 years ago
|
Attachment #185039 -
Flags: superreview?(bzbarsky) → superreview+
Comment 4•21 years ago
|
||
Comment on attachment 185039 [details] [diff] [review]
patch v1
r=jst
Attachment #185039 -
Flags: review?(jst) → review+
| Assignee | ||
Comment 5•21 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•21 years ago
|
||
Comment on attachment 185039 [details] [diff] [review]
patch v1
a=chofmann
Attachment #185039 -
Flags: approval1.8b3? → approval1.8b3+
| Assignee | ||
Comment 7•21 years ago
|
||
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Comment 8•21 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•21 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
•