66404 - Conn - browser is blocked in DNS lookup when a "bogus" home page is set in the prefs

Status: RESOLVED WORKSFORME

(Core :: Networking, defect)

Description

[Hervé Renault]

in the prefs, set your home page location to a bogus domain name, such as url
http://www.vinc17.org/ and set "when navigator starts up..." to "home page".

open a new browser window and type an url in the urlbar. 
=> you can't go to any location until the dns lookup has timed out with a
"location was not found" alert box.

what it should do : moz should ignore the "start page" setting when you type in
the urlbar of your new window.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Possibly caused by bug 10733 (though the patch currently attached to 10733 is
unlikely to fix this one).

Comment 2

[Keyser Sose]

Marking NEW.

Comment 3

[Asa Dotzler [:asa]]

over to XPApps

Comment 4

[Viswanath Ramachandran]

alec - does this have anything to do with our URLBar FE code or does the malaise
lie deeper ? thanks, VIshy

Comment 5

[Alec Flett]

I believe this a network bug. reassign to darin, who owns other dns issues.

Comment 6

[Darin Fisher]

on XP_UNIX (linux included) we do not have an asynchronous DNS lookup, which
means that only one lookup can happen at a time and moreover it means that
we are forced to wait for erroneous lookups to complete.  what we need is a
true asynchronous DNS implementation.

bug 10733 blocks this, and Boris is correct... the current fix for that bug
will not improve the situation here. either we need to move DNS resolution
out of process or we need NSPR 4.1, which provides a reentrant version of
PR_GetIPNodeByName().

Comment 7

[sairuh (rarely reading bugmail)]

-> networking and tever for qa.

Comment 8

[Darin Fisher]

Bug 10733 has been "fixed" and bug 70213 was opened to track further
enhancements to the problem at hand.  So, I'm marking this bug as dependent
on bug 70213.

Comment 9

[Darin Fisher]

how has the 10733 patch landing effected this bug?

Comment 10

[benc]

qa to me.

Comment 11

[slice1900]

Since NSPR 4.2 has landed, is this now fixed, or is the "rework" noted in 10733
for after NSPR 4.1's async DNS still required for this to be really and truly
fixed the right way?

Comment 12

[Darin Fisher]

WORKSFORME NS6.1 linux

Comment 13

[benc]

reporter:

This bug is a "futured" or "untargeted" bug which has been "resolved/works for
me". Most bugs meeting this criteria are usually somewhat out of date or working
in the current builds.

If this bug is not happening for you in a recent build (such as the Mozilla
daily build, Mozilla 0.9.3, or Netscape 6.1), please use the friendly "Mark bugs
as VERIFIED" radio button to set this bug to "VERIFIED/WORKS FOR ME"
If you reported the bug on a platform (e.g. Linux) and other contributors
reported on another platform (e.g. Mac OS), please comment that it works for you
 but do not verify it yet.

For these multi-platform bug reports, we need to verify all reported platforms
-OR- create new "still broken on platform X" bugs when you verify.