257420 - blocking other connections when waiting for one

Status: RESOLVED WORKSFORME

(Core :: Networking, defect)

Description

[r0polach]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040626 Firefox/0.8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040626 Firefox/0.8

In Firefox browser (0.9.1):
when user open more urls in new windows in background
and some of contacted sites does not respond,
other connections wait for timeout of blocked one,
even if they try to connect different sites.
Clicking "stop" on window with blocking connection helps
and other windows load page contents quickly after that.


Reproducible: Always
Steps to Reproduce:

Comment 1

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Are you using a proxy server?

Comment 2

[Benjamin Smedberg]

Are these other tabs from the same server? We have a pref that limits
connections-per-server to 8.

Comment 3

[r0polach]

ad comment#1: no, no proxy set

ad comment#2: no, other tabs connecting to different server
(according to url... and it is very very low probability that
all waiting tabs' url-domains point to same server - tested
on about 10 simoultaneously open tabs)

note: I guess it is dependent on in which phase of connection-eshtablishing
freezes...

Comment 4

[eyv]

I seem to be experiencing the same problem. Not much to add to the bug report.

Comment 5

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 6

[r0polach]

i have sometimes still seen this problem (firefox 1.0.6/7)
so i realy thing it is not solved yet.
the second user has already confirmed he see the problem too
(see #4)

Comment 7

[Jo Hermans]

(In reply to comment #6)
> i have sometimes still seen this problem (firefox 1.0.6/7)
> so i realy thing it is not solved yet.
> the second user has already confirmed he see the problem too
> (see #4)

The reminder asked if this still occurs in Firefox 1.5 beta 1, which is 1 year
*newer* than 1.0.*

Comment 8

[Darin Fisher]

-> default owner

Comment 9

[Mark Stier]

I have that problem with all Firefox 3 versions up to the recent one (3.03) (next excluding earlier ones).

When waiting for a server reply, new page loads are blocked *exactly* if DNS lookups are NOT cached and need to be executed. To me it looks like waiting for server replies/connection establishment at the TCP level (?) is blocking DNS Lookups or they are both even serialized...???

My system:

~# cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=8.04
DISTRIB_CODENAME=hardy
DISTRIB_DESCRIPTION="Ubuntu 8.04.1"

# uname -a
Linux d810 2.6.24-21-generic #1 SMP Tue Oct 21 23:43:45 UTC 2008 i686 GNU/Linux

Comment 10

[Matthias Versen [:Matti]]

new based on last comment

Comment 11

[Wayne Mery (:wsmwk)]

r0polach, Mark, can you still reproduce using trunk build/4.0beta?

Comment 12

[Patrick McManus [:mcmanus]]

there are some limits, per origin and global that are intentional. Generally they should not come into play on the real web. please update with a current test case if that's not true.