Closed Bug 177863 Opened 22 years ago Closed 21 years ago

Parsing & in address strings.

Categories

(Core :: DOM: HTML Parser, defect)

Product:
Core
Component:
DOM: HTML Parser
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: daniel, Unassigned)

References

(
URL
)

Details

(Keywords: helpwanted)

Attachments

(1 file)

Testcase
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.
Is there a particular page where this is a problem? In standards mode, we should be doing exactly what you say...
This look like a duplicate of 94651
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&amp;Thread=20021029225704Subhuman&amp;Comment=20021029225704Subhuman.xml" ID=EditComment>
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
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.
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 "&amp;" 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"
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&amp;z=7"); --> </script> firefox wont recognize the z variable.
That's because HTML entities are NOT expanded in scripts in HTML. So the behavior described in comment 9 is correct.
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.
URL: http://www.austinvolleyball.com/
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.
boris, timeless: are you saying that this bug is invalid? that we should not try to emmulate IE behavior here?
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.
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 &amp; 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&amp;mapURL=/images_b2c/maps/local/mwest/mi.gif&amp;disclaimerURL=/images_b2c/maps/local/local_text.gif&amp;planCatDisplayName=Local DigitalChoice&reg
Attached file Testcase —
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: 21 years ago
Resolution: --- → WORKSFORME
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.

Attachment

General

Creator:
Created:
Updated:
Size: