Closed
Bug 378210
Opened 18 years ago
Closed 17 years ago
fresh profile first run behind mean proxy stalls for minutes before window appears
Categories
(Firefox :: General, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: tuukka.tolvanen, Unassigned)
References
Details
Attachments
(1 file)
|
56.76 KB,
text/plain
|
Details |
firefox trunk from today, linux
1. stand behind proxy such that stuff outside resolves but can't respond
2. start firefox on unused profile
-> takes a few minutes before browser window appears
This connection attempt
:43255 static-mozorg.nllb.nl.mozilla.com.:www SYN_SENT
was sitting there during that time, and gone after window appeared.
|
Reporter | |
Comment 1•18 years ago
|
||
I was able to reproduce this in another setup by just denying 63.245.213.*:* on my router (guess that block depends on geography, ymmv) using a m.o 2007-04-20-20-trunk nightly. I wasn't able to reproduce with my own trunk build of 2007-04-20-18Z or m.o fx 2.0.0.1
|
|
Reporter | |
Comment 2•18 years ago
|
||
Here's the first request and its response, without the packet filter intervening
GET /projects/%APP%/%VERSION%/firstrun/ HTTP/1.1
Host: www.mozilla.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a3pre) Gecko/20070311 Minefield/3.0a3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
HTTP/1.1 400 Bad Request
Date: Sat, 21 Apr 2007 12:46:15 GMT
Server: Apache/2.0.52 (Red Hat)
Content-Length: 308
Connection: close
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
</p>
<hr>
<address>Apache/2.0.52 (Red Hat) Server at www.mozilla.org Port 80</address>
</body></html>
...and here's a list of requests to that ip block
GET /projects/%APP%/%VERSION%/firstrun/ HTTP/1.1
GET /firefox/headlines.xml HTTP/1.1
GET /en-US/firefox/headlines.xml HTTP/1.1
GET /projects/minefield/ HTTP/1.1
GET /projects/firefox/3.0a3pre/firstrun/ HTTP/1.1
|
|
Reporter | |
Comment 3•18 years ago
|
||
> 2007-04-20-20-trunk nightly. I wasn't able to reproduce with my own trunk build
...and that was due to building with official-branding; with minefield branding, the bug is reproducible
|
|
Reporter | |
Comment 4•18 years ago
|
||
|
|
Reporter | |
Comment 5•18 years ago
|
||
so startup.homepage_welcome_url is being treated as a "localized" pref; it's
http://%LOCALE%.www.mozilla.com/%LOCALE%/%APP%/%VERSION%/firstrun/
in firefox branding which fails to load quickly so the failing url is used as the pref end value; in minefield branding it's
http://www.mozilla.org/projects/%APP%/%VERSION%/firstrun/
which resolves and all and then goes sit on the network for some time trying to load the pref value from a props file on the other side of a firewall. Apparently the "if it loads then indirect, else use as such" ambiguity is a feature... Gavin suggested using a data url for the pref value, which is clearly insane ;) but the only minimal sort of thing that could work afaict. Yay.
|
||
Comment 6•17 years ago
|
||
This was fixed by bug 386696, right?
|
||
Comment 7•17 years ago
|
||
Actually this is a different bug.
Fix for this is to change:
http://mxr.mozilla.org/firefox/source/browser/components/nsBrowserContentHandler.js#542
overridePage = formatter.formatURLPref("startup.homepage_welcome_url");
to
overridePage = formatter.formatURL("startup.homepage_welcome_url");
startup.homepage_override_url appears to have the same problem.
I swear these values used to be complex preferences. But I guess not. I looked through the code and they never were.
|
|
||
Comment 8•17 years ago
|
||
I don't see how it's different. Bug 386696's patch means that we will no longer try to load the HTTP URI as a stringbundle, which is what caused the symptoms here. formatURLPref should be usable regardless of the pref type.
|
|
||
Comment 9•17 years ago
|
||
(In reply to comment #7)
> Fix for this is to change:
> overridePage = formatter.formatURLPref("startup.homepage_welcome_url");
> to
> overridePage = formatter.formatURL("startup.homepage_welcome_url");
That wouldn't work, because formatURL takes a string, not a pref name.
|
|
Reporter | |
Comment 10•17 years ago
|
||
wfm 2008080504 GranParadiso/3.0.2pre and 2008080702 Minefield/3.1a2pre
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•