All users were logged out of Bugzilla on October 13th, 2018
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.
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.
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
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
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.
Doing what the bugs says with the current trunk build (linux) *and* not escaping @ works fine ....
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).
with the fix for bug 108575 this problem should be fixed too ...
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.