Closed
Bug 105631
Opened 24 years ago
Closed 24 years ago
Click on URL and browser loads but does not render page
Categories
(Core :: Networking, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: reb, Assigned: neeti)
References
()
Details
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•24 years ago
|
||
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•24 years ago
|
||
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 3•24 years ago
|
||
Comment 4•24 years ago
|
||
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...
Assignee: asa → neeti
Component: Browser-General → Networking
QA Contact: doronr → benc
Comment 5•24 years ago
|
||
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 ...
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•24 years ago
|
||
Doing what the bugs says with the current trunk build (linux) *and* not escaping
@ works fine ....
Comment 8•24 years ago
|
||
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 ...
reb: URL treatment varies depending on the entry point (links, location, even
SRC and IMG tags).
Assignee | ||
Comment 10•24 years ago
|
||
cc'ing darin
Comment 11•24 years ago
|
||
with the fix for bug 108575 this problem should be fixed too ...
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•