Parsing & in address strings.

RESOLVED WORKSFORME

Status

()

RESOLVED WORKSFORME
16 years ago
15 years ago

People

(Reporter: daniel, Unassigned)

Tracking

({helpwanted})

Trunk
helpwanted
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
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...

Comment 2

16 years ago
This look like a duplicate of 94651
(Reporter)

Comment 3

16 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&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.  ;)

Comment 7

15 years ago
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

Comment 8

15 years ago
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.

Comment 9

15 years ago
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.

Comment 11

15 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

15 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

15 years ago
boris, timeless: are you saying that this bug is invalid?  that we should not
try to emmulate IE behavior here?

Comment 14

15 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

15 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 &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
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
Last Resolved: 15 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 18

15 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.