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

VERIFIED FIXED in mozilla0.9.2

Status

()

P4
normal
VERIFIED FIXED
18 years ago
7 years ago

People

(Reporter: gsa, Assigned: gagan)

Tracking

({perf})

Trunk
mozilla0.9.2
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
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
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.
OS: Mac System 9.x → All
Hardware: Macintosh → All

Comment 2

18 years ago
This is quite possibly just a polish bug but i will leave it till someone can
tell me for sure.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 3

18 years ago
-->dns
Assignee: neeti → darin

Updated

18 years ago
Status: NEW → ASSIGNED
Keywords: nsbeta1
Target Milestone: --- → mozilla0.9.1
(Assignee)

Comment 4

18 years ago
->gordon
Assignee: darin → gordon
Status: ASSIGNED → NEW

Comment 5

18 years ago
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?
Assignee: gordon → gagan

Comment 6

18 years ago
from mtg w/gagan: move target milestone to 0.9.2.
Target Milestone: mozilla0.9.1 → mozilla0.9.2

Comment 7

18 years ago
mass move, v2.
qa to me.
QA Contact: tever → benc

Comment 8

18 years ago
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

18 years ago
+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.



Depends on: 30917
Keywords: mostfreq
Summary: mozilla appears to try to resolve ip addresses → DNS: "Resolving" status takes too long
(Assignee)

Updated

18 years ago
Priority: -- → P4

Updated

18 years ago
Keywords: perf
(Assignee)

Comment 10

18 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 11

18 years ago
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 :-)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 12

18 years ago
This is were NS4 has its "Connecting to..." message I think. That would at least 
be less of a lie.
Don't we already have a bug on better status bar updates somewhere?
Whiteboard: duplicate?

Comment 14

18 years ago
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

18 years ago
"one of the first things I noticed" --- hear, hear, gagan :-)
(Assignee)

Comment 16

18 years ago
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. 
Status: REOPENED → ASSIGNED
(Assignee)

Updated

18 years ago
Summary: DNS: "Resolving" status takes too long → "Resolving <IP address>" shows up on status bar
(Assignee)

Updated

18 years ago
Whiteboard: duplicate?

Comment 17

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

Comment 18

18 years ago
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

18 years ago
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

18 years ago
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

18 years ago
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

18 years ago
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

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

Comment 24

18 years ago
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...

Summary: "Resolving <IP address>" shows up on status bar → DNS: "Resolving <IP address>" shows up on status bar

Comment 25

18 years ago
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...".
(Assignee)

Comment 26

18 years ago
Created attachment 38661 [details] [diff] [review]
patch based on gordon's suggestion. This fixes it!
(Assignee)

Comment 27

18 years ago
need approval...
Whiteboard: sr=darin, r=dougt, a=?
(Assignee)

Updated

18 years ago
Keywords: patch

Comment 28

18 years ago
a= asa@mozilla.org for checkin to the trunk.
(on behalf of drivers)approval noted in the bug.

--Asa
Blocks: 83989
(Assignee)

Comment 29

18 years ago
fix checked in v1.208 of nsSocketTransport.cpp
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED
Whiteboard: sr=darin, r=dougt, a=?

Comment 30

18 years ago
verified ...now says connecting to 207.200.81.215
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.