Closed Bug 177863 Opened 22 years ago Closed 20 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: 20 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: