85037 - often have to click link twice

Status: RESOLVED WORKSFORME

(Core :: Networking, defect, P3)

Description

[R.K.Aa.]

linux 2001060905

Often i have to click a link twice to make moz load a page.
It's somewhat intermittent, but a pretty reliable approach is this:

fill in counter.li.org in url-bar - hit enter
you get to http://counter.li.org
Let page load, then click link on top named "Statistics"

More often than not, Mozilla will now just spin the throbber, and status-bar
reads "Resolving host" or "Connecting to". It can seemingly spin forever - it
won't load anything till i click the link once more.


Another sample is when submitting queries in bugzilla. The first time i hit the
"Submit Query" button, nothing happens. "Resolving host" or "Connecting to.." is
all i see. When button is clicked once more, the query is submitted.

Comment 1

[Emlyn Shannon]

I can't reproduce this on the Macintosh build 2001060712

Comment 2

[R.K.Aa.]

It may be be cache related. I've been seeing this on and off in all builds - CVS
and official - since bug 81764. In bug 82181, now marked fixed,
[e-mail] comments he still sees this too.

Both those bugs are now considered fixed, but something remains wrong.

A fixes that went in around the time this bug appeared was for bug 72507
(checked in on the 18th). I believe I first noticed this bug on builds from May
19th.

Comment 3

[R.K.Aa.]

Resolving as dup of bug 85025 which was resolved WFM when i filed this one.

*** This bug has been marked as a duplicate of 85025 ***

Comment 4

[benc]

REOPENING:
This description doesn't have a DNS error (see comments in bug 85025).

Comment 5

[neeti]

I am having a hard time reproducing this. adding qawanted

Comment 6

[dave.close]

I don't find a need to click a link twice, but I do see excessively long
"resolving host" status before a page finally loads. I just saw it adding a note
to another bug. The note was eventually added, after about two minutes. But the
"resolving" message implies a DNS resolution delay which I don't notice anywhere
else. Perhaps the message is merely misleading and the true cause is that the
site is slow to respond. But if the request has actually been made while Moz
mis-reports that it is still trying to find the host, that may cause serious
troubles with any application that makes a cummulative change on the host (like
a banking app). The user might send the request multiple times, not suspecting
that it has been sent at all. My experience is with W2K; I've seen this on all
recent versions of Moz since 0.8.

Comment 7

[benc]

Very good point! I've made comments in Bug 72805 about changing the status so it
is more accurate. Can you read that bug and make a similar point there?

Meanwhile, we need to figure out why this load seems to drag out...

Comment 8

[R.K.Aa.]

It doesn't trigger after 2 minutes wait here. It doesn't trigger after 30
minutes wait either. At the point where nothing loads - there is no network traffic.

I tested something else: Often i also see that i can click a link 50 times to no
avail. a netstat |grep tcp then often reveal several open sockets to same URL,
all in state ESTABLISHED. If i then click "stop" button in browser and delete
cache, network traffic suddenly picks up again. Sniffing those packets with
Ethereal i see that the packets are coming from the expected sited.
However - since the "stop" button is now clicked in browser, nothing renders
there - it isn't loading a thing even if there's incoming data.

Clicking "reload" again will just hang the whole thing once more - traffic
halts. Seeing all kind of "Error loading URL" numbers - 2147746065 sometimes
repeat a few times, till all further attempts just spawn 2152398850

Comment 9

[Matthew Cline]

I'm experiencing the same behavior.  Error 2147746065 (0x80040111L)
seems to be NS_ERROR_NOT_AVAILABLE.  I get this error most often
at http://www.fanfiction.net/, on some of the dynamic pages.

Comment 10

[Matthew Cline]

Actually, what I've seen might not be an instance of this bug; in my
bug, it fails immediatly, rather than dragging things out.  But it gives
the same error code, and gets fixed up whent he cache is cleared.  I
filed a serarate bug as bug 86559.

Comment 11

[R.K.Aa.]

with a half hour old CVS build this bug suddenly changed for the better.
Suddenly i have a hard time reproducing it.

Comment 12

[R.K.Aa.]

Haven't seen this again. It really was horrible - for weeks on end. The only
relevant checkins i found for the periode between CVS builds with and without
this bug, were for bug 83332 and bug 82241. This is not at all an obvious dup
though - resolving as WFM.