Closed
Bug 177863
Opened 22 years ago
Closed 20 years ago
Parsing & in address strings.
Categories
(Core :: DOM: HTML Parser, defect)
Core
DOM: HTML Parser
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: daniel, Unassigned)
References
()
Details
(Keywords: helpwanted)
Attachments
(1 file)
92 bytes,
text/html
|
Details |
In order to comply with recent xhtml standards, a page is required to escape occurances of the ampersand character ('&') as '&'. This presents a problem, in that many websites use this character as a parameter-delimiter in address strings. I've noticed a few sites that, rather than change the character they use to separate param-value pairs, they instead replace the instances of '&' in links with '&'. When you click one of these links, rather than being sent to http://www.site.com/page.ext?name1=value1&name2=value2 as the page expects, Mozilla attempts to load http://www.site.com/page.ext?name1=value1&name2=value2, which invariably causes the page parsing the urlstring to die, or at least return incorrect results. I propose a simple fix to this, where if '&' is encountered in an address string, it is converted to '&' before the link is queried. History suggests it's generally easier to bend slightly to account for unusual web documents than to expect site designers/programmers to embrace common sense. I haven't encountered this behaviour on any other platforms, but that is only because I have not used Mozilla on any other platforms.
Comment 1•22 years ago
|
||
Is there a particular page where this is a problem? In standards mode, we should be doing exactly what you say...
Comment 2•22 years ago
|
||
This look like a duplicate of 94651
Reporter | ||
Comment 3•22 years ago
|
||
Notably when editing a post on www.carobit.com/CarobitExchange/ (needs registration to post however). The URL comes from a form submission: <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> [snip] <form name="EditComment" Method="post" action="ChangeComment.asp?Topic=Lounge&Thread=20021029225704Subhuman&Comment=20021029225704Subhuman.xml" ID=EditComment>
Comment 4•22 years ago
|
||
To parser. Daniel, thanks for the information; we should be in standards mode on that page..
Assignee: asa → harishd
Status: UNCONFIRMED → NEW
Component: Browser-General → Parser
Ever confirmed: true
QA Contact: asa → moied
Comment 5•21 years ago
|
||
Uh, bz, I just had occasion to look back over that piece of code, and harishd never checked in the quirks-mode-only conditional. IMO, we should fix that and knock out the silly 4xp "only values <= 255" constraint too.
Comment 6•21 years ago
|
||
Post a patch. ;)
The site "http://www.pcl.lib.wa.us/" manifests this problem. If, for example, you select the first entry from the "My Library Account" sub-menu Mozilla will try to load a URL with "&" in it where there should be a "&". The site does not manifest this behavior with IE5. I haven't tried later versions of Netscape. The site says it's a "Horizon Information Portal 2.1" and "Powered by Dynix"
Updated•21 years ago
|
Assignee: harishd → parser
Severity: trivial → normal
Keywords: helpwanted
OS: Windows ME → All
Hardware: PC → All
The site "http://www.pcl.lib.wa.us/" has been fixed and no longer exhibits this problem. Sorry, but it looks like there was a local level involved in the implementation of the site that I was unaware of.
I encounter this bug only when the browser changed his address by javascript like: <script language="javascript"> <!-- location.replace("/da.phtml?m=3&z=7"); --> </script> firefox wont recognize the z variable.
Comment 10•20 years ago
|
||
That's because HTML entities are NOT expanded in scripts in HTML. So the behavior described in comment 9 is correct.
Comment 11•20 years ago
|
||
This bug appears to cause trouble for Mozilla on http://www.austinvolleyball.com/ Steps to reproduce: (1) click one of the links on the lower right hand side of the page under the section titled "VOLLEYMAPS" (2) notice that you are prompted by mapquest to choose the correct "austin", and doing so results in only a generic map of austin instead of a map giving an exact location of a place to play volleyball. This is not a problem in IE.
Comment 12•20 years ago
|
||
darin: javascript:var temp = window.open('http%3A%2F%2Fwww%2Emapquest%2Ecom%2Fmaps%2Fmap%2Eadp%3Fcity%3Daustin%26amp%3Bstate%3DTX%26amp%3Baddress%3D2400%2BBarton%2BSprings%2BRoad%26amp%3Bzip%3D78746%26amp%3Bcountry%3Dus%26amp%3Bzoom%3D7','myInfo'); see comment 10.
Comment 13•20 years ago
|
||
boris, timeless: are you saying that this bug is invalid? that we should not try to emmulate IE behavior here?
Comment 14•20 years ago
|
||
darin: comment 3 references a non javascript issue. so this bug is about that. i'm not going to argue validity, that's not my realm.
Comment 15•20 years ago
|
||
Another site where this is causing a problem is www.verizonwireless.com When you view their plans and try to view a coverage map, the window opens and nothing is displayed because the URL for the map window contains & between the variables of the URL. Here is an example of the URL that opens in the new winow: www.verizonwireless.com/b2c/store/coveragemap.jsp?item=planFirst&mapURL=/images_b2c/maps/local/mwest/mi.gif&disclaimerURL=/images_b2c/maps/local/local_text.gif&planCatDisplayName=Local DigitalChoice®
Comment 16•20 years ago
|
||
Comment 17•20 years ago
|
||
The testcase worksforme, as do various other attempts to make this break (eg see http://www.mozilla.org/contribute/hacking/first-bugs/ -- the links there work fine). The code in ConsumeAttributeEntity (nsHTMLTokens.cpp) looks pretty much correct except for the ">255 not terminated with a ';'" quirk that IE has. Comment 15 has the same problem as comment 9 and comment 11 -- that code is working like it's supposed to. The strings passed to window.open there are NOT run through the HTML parser. Marking worksforme, but if this is still a problem please reopen and attach a testcase showing the problem...
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Comment 18•20 years ago
|
||
Yeah, the page on which I originally noted the problem is working properly for me now (Mozilla 1.7b, FreeBSD).
You need to log in
before you can comment on or make changes to this bug.
Description
•