869 bytes, patch
|Details | Diff | Splinter Review|
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 22.214.171.124" Reproducible: Always Steps to Reproduce: 1.in url bar input http://126.96.36.199 2.hit enter key 3.look next to barber pole the networking message will say "Resolving host 188.8.131.52" Actual Results: saw networking message say "Resolving host 184.108.40.206" 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://220.127.116.11 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
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
Assignee: neeti → darin
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.1
Assignee: darin → gordon
Status: ASSIGNED → NEW
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
from mtg w/gagan: move target milestone to 0.9.2.
Target Milestone: mozilla0.9.1 → mozilla0.9.2
mass move, v2. qa to me.
QA Contact: tever → benc
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.
+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
Summary: mozilla appears to try to resolve ip addresses → DNS: "Resolving" status takes too long
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
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 → ---
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?
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).
"one of the first things I noticed" --- hear, hear, 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.
Status: REOPENED → ASSIGNED
Summary: DNS: "Resolving" status takes too long → "Resolving <IP address>" shows up on status bar
*** Bug 85612 has been marked as a duplicate of this bug. ***
How about "Looking for 18.104.22.168" 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?
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.
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.
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??
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.
good suggestion... that would happen in the trivial cases as well as in the cached case.
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
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...".
Created attachment 38661 [details] [diff] [review] patch based on gordon's suggestion. This fixes it!
Whiteboard: sr=darin, r=dougt, a=?
a= email@example.com for checkin to the trunk. (on behalf of drivers)approval noted in the bug. --Asa
fix checked in v1.208 of nsSocketTransport.cpp
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago → 18 years ago
Resolution: --- → FIXED
Whiteboard: sr=darin, r=dougt, a=?
verified ...now says connecting to 22.214.171.124
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.