105631 - Click on URL and browser loads but does not render page

Status: RESOLVED FIXED

(Core :: Networking, defect)

Description

[reb]

From Bugzilla Helper:
User-Agent: Mozilla/4.78 [en] (Windows NT 5.0; U)
BuildID:    2001101117

After clicking on a link nothing is rendered in the browser.
Copying the link address to the address bar results in the
page being properly displayed (though Mozilla causes errors
in the underlying application due to Mozilla bug #71422.)

Reproducible: Always
Steps to Reproduce:
1. Go to http://public.perforce.com/public/index.html
2. Click on the word "Public" just under "The Depot Roadmap"
   (or any of the links in that section)
3. The browser will hang and after a minute or two it will
   report "Document: Done"
4. Right-click the same link and select "Copy link address"
5. Paste this into the address bar and hit "return"
6. The page will display

Expected Results:  Mozilla should have rendered the page.

Comment 1

[gavin long]

I have problems with that page too, 2001101803, Win98SE.

For me, the throbber just keeps on going.  I didn't get document done in the 10
mins I waited until my patience ran out.

Something strange is going on, though:

Using IE5.5, I followed the same link.  Page came up in a couple of seconds.  

(NB Embedded within the page was a user-agent string, so something is
dynamically generating the page)

Then I saved the source from IE to a local file, and opened THAT with Moz.  Page
came up in a few seconds without a hitch.  

So, I think the script at the other end is doing something differently, based on
the user-agent string, and Moz doesn't like whatever it's doing.

I've got no idea what's going on here.  I'll go poke around a bit more, see what
I find.

Comment 2

[gavin long]

whoa! 0.9.4 does something completely different.

The page loads in seconds, but shows the following in the main part of the page:

-------------------------start
Showing depot path:
//@md=d&cd=//&sr=ra=s@/public/&c=8xP@//...


Unintelligible revision specification 'md=d&cd=//&sr=ra=s@/public/&c=8xP@//*'.


Unintelligible revision specification 'md=d&cd=//&sr=ra=s@/public/&c=8xP@//*'. 
-------------------------end

looks like moz is giving the server-side scripts a slight case of indegestion.

When the page loads, the URL shown in the location bar changes, to:

IE5.5: 
http://public.perforce.com:8080/@md=d&cd=//public/&c=XXX&ra=s@//public/?ac=83

NN4.75:
http://public.perforce.com:8080/@md=d&cd=//public/&c=XXX&ra=s@//public/?ac=83

0.9.4: 
http://public.perforce.com:8080/%40md=d&cd=//&sr=ra=s%40/public/&c=XXX%40//?ac=83

where XXX appears to be a random collection of numbers & letters.

My _GUESS_ is that Moz (0.9.4, at least) is escaping the "@" signs in the URL,
and the server doesn't like it much.  Doesn't explain where the extra
"&sr=ra=s%40/" came from, though.

[goes dupe-hunting]
If that _IS_ the problem, this could be another instance of bug 96519.  

But that doesn't explain why 0.9.5 (and my more recent nightly) just sit there
forever without rendering anything.  I think we need someone who can have a look
at the communications that are going on between moz and the server.

Confirming, because there's definitely a problem SOMEWHERE, but leaving on
Browser-General for now, because I've got no idea where the problem lies.

Reporter:  My keen sense of intuition (and your e-mail address) tells me that
you may be able to shed some light on what's happening server-side.

Comment 3

[gavin long]

Doh! 

Read, the bug, Gav, read the bug.  The reporter has already pointed out bug
71422, which IS another instance of bug 95619.  (Sorry Reb)

Comment 4

[gavin long]

OK, so the page loads in 0.9.4, but not in 0.9.5 -> regression.

It's probably not the server-side script, since that copes with 0.9.4 fine
(modulo bug 71422)

Moz _thinks_ it's getting most of the data, (the progress bar gets to about
100%) but the throbber keeps on doing its stuff.  There doesn't appear to be
anything too difficult to render in there, so I doubt it's supposed to be
processing for all that time.

Either (a) networking is horked somehow and we're not getting all the data, or
(b) the rendering is getting stuck somewhere.

From the reporter's experience, I'd guess (a), so it's over to networking...

Comment 5

[Andreas Otte]

I've reread rfc2396. We might loosen up on escaping @ inside the directory
component of the url. Since @ has no special meaning inside the urlpath we can
do whatever we want, escape it or not. The failing page clearly points to an
error inside the application. But as I said, we might help a bit by not escaping
@ inside the directory component of the url ... I have to do some more tests ...

Comment 6

[reb]

the @ to %40 translation is IMHO a completely separate issue.

What I found strange (and why I filed the bug) was that the browser
behaved differently when I selected the link from a web page and
when I just cut/pasted it into the address bar.

Comment 7

[Andreas Otte]

Doing what the bugs says with the current trunk build (linux) *and* not escaping
@ works fine ....

Comment 8

[Andreas Otte]

So, without escaping @ both ways work fine ... not so unrelated I think. If I
remember correctly mozilla behaves a little bit differently with redirection
when clicking a link or having the url in the urlbar. Clearly with %40 the
redirection does something wrong ...

Comment 9

[benc]

reb: URL treatment varies depending on the entry point (links, location, even
SRC and IMG tags).

Comment 10

[neeti]

cc'ing darin

Comment 11

[Andreas Otte]

with the fix for bug 108575 this problem should be fixed too ...