72805 - DNS: "Resolving <IP address>" shows up on status bar

Status: VERIFIED FIXED

(Core :: Networking, defect, P4)

Description

[gsa]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; N; PPC; en-US; 0.8.1) Gecko/20010320
BuildID:    2001032008

mozilla appears to try to resolve ip addresses before loading them
ex. seeing network message next to barber pole that says "Resolving host
207.200.81.215"


Reproducible: Always
Steps to Reproduce:
1.in url bar input http://207.200.81.215
2.hit enter key
3.look next to barber pole the networking message will say "Resolving host
207.200.81.215"

Actual Results:  saw networking message say "Resolving host 207.200.81.215"

Expected Results:  expected that ip addresses wouldn't need to be resolved or
reverse dns'd to load or be accessible on a tcp/ip network

mozilla should just load the ip address not try to resolve or reverse dns it

Comment 1

[Boris Zbarsky [:bzbarsky]]

I'm seeing that message on Linux too.  Particularly noticeable if you choose an
IP for a computer that's not responding, like http://18.243.0.166

I think we just put up the "resolving" message from the time the user hits enter
to the time when we actually connect to the server....  This does not mean we're
doing a DNS resolution the whole time.  This message is also shown during the
attempt to create the actual connection once the IP address is known.

Comment 2

[Keyser Sose]

This is quite possibly just a polish bug but i will leave it till someone can
tell me for sure.

Comment 3

[neeti]

-->dns

Comment 4

[Gagan]

->gordon

Comment 5

[gordon]

No, we are not resolving the ip numbers.  Take a look at 
nsDNSLookup::InitiateLookup() at:

http://lxr.mozilla.org/seamonkey/source/netwerk/dns/src/nsDnsService.cpp#529

we explicitly check for ip dot addresses and bypass the gethostbyname (or 
equivalent call).

This bug demonstrates the status update problem, where it *looks* like we're 
spending a long time in DNS, when actually we're done with it and taking a long 
time doing something else which hasn't reported any status :-(

Gagan, isn't there another bug on this already?

Comment 6

[lchiang]

from mtg w/gagan: move target milestone to 0.9.2.

Comment 7

[benc]

mass move, v2.
qa to me.

Comment 8

[rbs]

gordon wrote:
> This bug demonstrates the status update problem, where it *looks* like we're 
> spending a long time in DNS, when actually we're done with it and taking a
> long time doing something else which hasn't reported any status :-(
>
> Gagan, isn't there another bug on this already?

I was specifically looking at such a bug, but couldn't find any. Is there?
It is a nasty bug because it gives the 'perceived' impression that Mozilla is 
sluggish, when actually it isn't. 

If the status bar is updated with the next message as soon as possible, then at 
least, the 'perceived' blame could be placed on the WWW (World Wide Wait :-) and 
Mozilla wouldn't be 'appearing' to try to resolve IP addresses as the bug title 
says.

Comment 9

[benc]

+mostfreq

Since the discussion here and in bug 74153 have been inconclusive as to whether
DNS is the ONLY reason why this status message is displayed for so long, I'm
collecting reports about the status message here.

marking dependent on Bug 30917 "implement DNS caching and request cancelation".

Lets see how this changes once that is fixed.

Comment 10

[Gagan]

Even though I agree that we should not be displaying a "resolving" status
message for an ip address, gordon confirms it that we don't actually lookup so
at this stage this bug is merely a cosmetic fix at best. The original issue of
resolving taking a long time should now be much less visible with DNS caching in
place. I am going to mark this as fixed based on these comments. If someone
disagrees then feel free to open this with your reasons.

Comment 11

[rbs]

Re-opening to request reconsideration. Indeed, it is just a matter of
perception. But that's exactly where the difference lies. I tried putting a
break during layout (specifically during style resolution -- where style sheets
are supposed to have all been loaded), and the "resolving DNS" status message is
there, during layout...

It would be appreciated if something can be done about this. (BTW, one of my
criticisms of IE is just that its DNS status message takes too long :-)

Comment 12

[Daniel Bratell]

This is were NS4 has its "Connecting to..." message I think. That would at least 
be less of a lie.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Don't we already have a bug on better status bar updates somewhere?

Comment 14

[Brian Hauer]

I can't say for certain, but I am pretty convinced that this is just related to
the status bar not refreshing, as has been noted by many people above.  I
sincerely doubt that it's related to any real delays in resolving a name or any
effort by Mozilla to actually resolve IP addresses.  I just yesterday grabbed
Mozilla 0.9.1 (first time I've looked at it since a very early alpha--I am
-really- impressed!), and one of the first things I noticed was the lack of a
progression from:

- Resolving www.netscape.com...
- Connecting to www.netscape.com...
- Transferring data...

In Mozilla, it seems you indeed see the Resolving status for at least the two
first steps (resolving and then establishing a connection).

Comment 15

[rbs]

"one of the first things I noticed" --- hear, hear, gagan :-)

Comment 16

[Gagan]

alright alright. Here is what I have done-- since I couldn't find the bug that 
dealt with late status bar updates I created a new one (bug 85551) that way we 
can track it separately. 

As for the remaining problem in this bug it seems that we still need to prevent 
the "resolving ddd.ddd.ddd.ddd" message from appearing since clearly we are not 
doing a lookup. Changing the summary as such. 

The actual fix for something this small may be a little bit more tricky. The 
socket transport has state machine logic that forces a lookup (even for IP 
addresses) as a part of its switching to different states. We'd need a way for 
SocketTransport to skip over that step in case of IP addresses. cc'ing rpotts 
who put in the glorious states of the socket transport. 

Comment 17

[rbs]

*** Bug 85612 has been marked as a duplicate of this bug. ***

Comment 18

[Daniel Hill]

How about "Looking for 1.2.3.4" and "Looking for www.mozilla.org"? I think the 
average user will understand that terminology rather than 'Resolving', and 
doesn't look silly when a numeric IP is used.

Thoughts?

Comment 19

[R.K.Aa.]

Only "Looking for www.mozilla.org" sounds a little too physical, and more like a
question than a server lookup. Sounds funny to me. "Looking up.." would be more
appropriate, if wording is to be modified.

Comment 20

[Darin Fisher]

the socket transport should just call PR_StringToNetAddr before even talking to 
the DNS service.  if PR_StringToNetAddr is successful, then we could bypass the
DNS service and simply not post any status.

Comment 21

[Darin Fisher]

we probably also don't want to post this status message if we are just using
local the DNS cache or resolving localhost.  perhaps we need to make the DNS 
service responsible for posting this event??  or, perhaps the OnStartLookup
could have a status code that tells us what kind of "work" was necessary to
resolve the host??

Comment 22

[gordon]

How about if the lookup has already completed, nsSocketTransport::Process()
doesn't call OnStatus(NS_NET_STATUS_RESOLVING_HOST). 
nsSocketTransport::doResolveHost() already checks to see if the lookup is complete.

Comment 23

[Darin Fisher]

good suggestion... that would happen in the trivial cases as well as in the
cached case.

Comment 24

[benc]

I propose the following:

If we are doing name resolution say "Resolving: FQDN". Since DNS resolution is
wrapped inside other forms of name resolution these days (/etc/nsswitch.conf and
GKW on MacOS and Windows), basically we call the OS and pray, so we should be
suitably vauge.

We should not do this for IP addresses, because its not what is going on, (and
people file bugs and think Gordon is slowing everyone down...)

We should then say "Connecting" when the resolution completes. We are no longer
resolving, so lets change the status (so people don't file more bugs about how
DNS is slowing everythign down when it isn't).

Once data starts to flow, there is an existing "transfering" message, which I
like more than Communicator's "waiting for...".

I think this set of status messages would be ideal, because it is both
reasonably accurate about what is going on, and also useful for troubleshooting.

Probably some additions need to be made to my proposal to accomodate caching
(DNS and disk)

For example, if we get performance complaints on a site, and someone says "it's
that DNS being slow...", we can tell them to lookup the IP address and punch it
in, and see if it goes faster...

Comment 25

[dave.close]

I also see excessively long "resolving host" status before a page finally loads,
both for names and numbers. 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 isn't correct. Based on other comments
here, 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.

Personally, I am not fond of the "Transfering data from..." status. I use an
external modem. Usually when that message is displayed, there is no activity on
the modem at all. So the message is a lie. It might be better to say something
like, "Ready to accept data from...".

Comment 26

[Gagan]

Attachment: patch based on gordon's suggestion. This fixes it!

Comment 27

[Gagan]

need approval...

Comment 28

[Asa Dotzler [:asa]]

a= [e-mail] for checkin to the trunk.
(on behalf of drivers)approval noted in the bug.

--Asa

Comment 29

[Gagan]

fix checked in v1.208 of nsSocketTransport.cpp

Comment 30

[Sivakiran Tummala]

verified ...now says connecting to 207.200.81.215