If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

msdn pages never stop loading & stop button doesn't stop 'em

VERIFIED WORKSFORME

Status

()

Core
Networking
--
minor
VERIFIED WORKSFORME
16 years ago
14 years ago

People

(Reporter: Robert Praetorius, Assigned: neeti)

Tracking

Trunk
mozilla1.0
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

16 years ago
I've noticed with a number of msdn pages that the throbber
never stops.  Also, neither <esc> nor the stop button stop
the throbber.  The status bar will say Tranferring data
from msdn.microsoft.com... for as long as I care to leave it
there.  However, the page contents do appear to have 
loaded completely.

Going to another page and then coming back usually will
result in loading the page & the throbber stopping.

Also broken in Netscape 6.2.  Works in Netscape 4.78.

I checked some other related bugs (with stop and load as
substrings in summary) and tried the URLs in them and
they all finished loading.  So I'm guessing this is a
new and separate beast.

Comment 1

16 years ago
Odd. The page loads quickly on a day old Linux build, and finished right away.
But afterwards my firewall kept getting hit on ports 36797 upwards from
msdn.mmicrosoft.com.
Could this be some firewall issue?

Comment 2

16 years ago
Robert, please always state your build ID in your bug reports.  This page loaded
fine with 2001-12-13-03 under W2K twice and then never quit the third time for
me and stop did nothing.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 3

16 years ago
oops.  Sorry 'bout that.  To quote from Bugzilla:

Some fields initialized from your user-agent, Mozilla/5.0
(Windows; U; WinNT4.0; en-US; rv:0.9.6) Gecko/20011120

Specific build Id was (is) 2001112009.  BTW, if Bugzilla
knows all of the above, why doesn't it log it?  Perhaps
I should file that as a feature request for Bugzilla...
(Reporter)

Comment 4

16 years ago
ya know what?  I went back to the URL in this report and it
loaded fine.  I cleared cache, tried again and it was still
OK.  But when I tried some new search terms and followed the
links on the results for those, I was back to eternal throbbing.

So you may need a link from a fresh query to get it to break.
Breaks for me, anyway:-)

Comment 5

16 years ago
Robert Praetorius: What are your cookie prefs?
(Reporter)

Comment 6

16 years ago
ccokies prefs?  Good question, shoulda thoughta that.
Enable cookies for the originating web site only.  But I
just tried Enable all cookies and the behavior didn't
change.

Another bit of info - yes, I am behind a firewall.  And
it is blocking some ports (I don't have a list - the firewall
is at another site and we're on an FR PVC to it) and doing
NAT.

Comment 7

16 years ago
->networking
Assignee: asa → neeti
Component: Browser-General → Networking
QA Contact: doronr → benc

Comment 8

16 years ago
reporter, can you get a network trace?

There a couple ways to do this.  I like the tool ngrep which is freely available.
Target Milestone: --- → mozilla1.0
(Reporter)

Comment 9

16 years ago
(this is the original reporter, rpraetorius@aspenres.com)

WFM today with 0.9.8

We'll see if the fix persists (I've gotta revisit my buglist
when 0.9.9 arrives to recheck
http://bugzilla.mozilla.org/show_bug.cgi?id=117247), so I'll
try to remember to re-check it then).

Was anybody else ever able to reproduce this?
(Assignee)

Comment 10

16 years ago
marking wfm per comments above
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 11

16 years ago
(this is the original reporter)

the fix persists in 0.9.9
Generalissimo Francisco Franco is still dead.

Comment 12

14 years ago
verified working, 1.4rc3 on win2k.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.