489772 - Open URLs in new thread not in main thread (both tabs and windows)

Status: RESOLVED DUPLICATE of bug 235853

(Core :: Networking, defect)

Description

[Kosta]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5

So we got proxy server and seems to me slow internet.
This causes Firefox 3.0.5 and I remember that all the previous versions back to 
Firebird 0.5 has the following bug:
Opening a URL requires opening Socket on the TCP/IP and the server slowly responses to that since the high traffic of other packets. So opening in new tab or windows actually freezes the whole browser until response is reseived.
And this is very bad since I got other tabs/windows to read and browse but I CANNOT use the Firefox until the SYN_ACK packet is received from the server.
This happens because in the main thread or in the thread that renders the view/GUI and Events is used to open Socket. This should never be done not only in java but in your source. I'm java developer that is why I know so much.
Please move this socket opening code to another thread and run it in low then normal priority. It is a lot of versions released of Firefox and seems nobody mentioned that.

Reproducible: Always

Steps to Reproduce:
1.open some tabs in a low bandwith internet connection like modem or so - or use 
a slowed proxy , or download a lot or gigabytes and brose the same time
2.open some remote with many hops/routers URL - you can use tracert to see how many hops it needs.
3.In some point of opening the URLs you will see that whole browser freezes instead to allow access to other tabs.

Actual Results:  
In some point of opening the URLs you will see that whole browser freezes instead to allow access to other tabs.

Expected Results:  
Not freezing but rather waiting tabs/windows to download the contents and other tab/windows already opened to be browseble and scrolable. Not blocked access to the menus as well.

It could be also affected from the many extensions I use.
Some are slowing the browsing by parsing/searching the page for the keywords.
I do not think this is the problem because I encountered the problem without any extensions installed in previous versions.
However if this is the problem then the javascript engine has to be run in another thread with low priority and not blocking the view.
Perhaps I have to post another bug for that problems as well.
I know something for extension development as well.
Here are my extensions:
Adblock 0.5.3.043
All in one sidebar 0.7.6
Bookmark Duplicate Detector 0.7.2
Calculator 1.1.12
Compact Menu2 2.2.0
Context Search 0.4.3
Converter 0.7.1
FAYT 2.0.4
Firebug 1.2.1
Flashblock 1.5.7
FlashGot 1.1.5
Forecastfox 0.9.7.7
Free Download Manager plugin 1.3.4
Greasemonkey 0.8.20080609.0
Image Zoom 0.3.1
Launchy 4.2.0
Linky 2.7.1
Nuke Anything Enhanced 0.68.2
SearchBox Companion 1.77
Tab Mix Plus 0.3.7pre.080930
Text2Link 1.9.1
Web Developer 1.1.6
Wired Marker 2.0.08072400

Comment 1

[Wayne Mery (:wsmwk)]

can you reproduce in safe mode using FF 3.5 beta?
 http://www.mozilla.com/en-US/firefox/all-beta.html

Comment 2

[timeless]

so.... PAC is currently handled on the main thread, this is indeed a known bug, but fixing it is mildly painful.

If your proxy doesn't absolutely require that you use a PAC file, i'd encourage you to try manually configuring it instead.

Comment 3

[Tracy Walker [:tracy]]

clueless triager question; is this a dupe of bug 364223 or a valid bug in its own right?