On 9/6/05, Joseph S. Huang <[EMAIL PROTECTED]> wrote: > A better way than disabling keyword search to fix #15848 would be to fix > the keyword functionality, by sending strings which start with a > protocol (such as http://) and don't resolve in DNS to an error page, > instead of doing a search. That's what I figure from reading the liked > Mozilla bug, anyways. >
A problem with that is that many entered strings that are meant to be URLs don't start with a protocol. You enter 'gnome.org' or 'localhost', not bothering with the protocol. The current workaround for several browsers seems to be to identify everything with a dot present as an URL, even when they are clearly not, as in normal sentences with trailing space after the dot, or a string ending in a dot. Even taking that into account, it means that me searching for 'document.pdf' fails because it look like an URL - and on some internal companies LAN or in the future it might be a valid URL, further complicating matters. That's why I think it's intiutive to try DNS for everything that might be valid and if there's no hit, try a search instead. If the site is down, but exists in DNS, there is no search - the browser has already moved on to trying a fetch. If that fails, error messages are appropriate. If it doesn't exist in DNS, chances are that you meant a search (or that you are mistaken about the URL, in which case a search also might help). This goes for strings that *do* start with http:// as well. If you do surf sites that, if misspelled or removed from DNS, are so sensitive that it would be a real concern to have them forwarded to a search engine, then by all means it should be possible to disable. I don't want to deny anyone that right, I just don't see how that is even remotely the common case. -- Kristoffer Lundén ☎ 0704 48 98 77 ✉ [EMAIL PROTECTED] ICQ: 618 289 83 http://www.gamemaker.nu/
_______________________________________________ epiphany-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/epiphany-list
