GNOME Bugzilla – Bug 752510
local network hostname in URL bar results in using default search engine
Last modified: 2015-09-29 18:37:47 UTC
Steps to reproduce: 1. open epiphany 2. add a local url, e.g. fritz.box if you have a Fritz!Box. press Enter What happens? Epiphany uses the default search enigne to search for fritz.box. What is expected? Epiphany should load the website from fritz.box Additional info: Firefox does as I expected: it loads http://fritz.box/ If you put http://fritz.box/ into epiphany's URL bar, it will load this page fine, so there is no DNS issue.
To debug this, I would look at ephy_embed_utils_normalize_or_autosearch_address(). In particular, I guess the call to is_public_domain() in ephy_embed_utils_address_is_valid() will of course fail here. We should figure out how Firefox handles this: I can't imagine they resolve the name first to see if it works, because that could be slow....
On my local network, fritz.box currently has the IP address 192.168.2.1 according to $ strace -f -e connect firefox --new-instance --ProfileManager … [pid 1171] connect(57, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.2.1")}, 16) = 0 [pid 1171] connect(57, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("192.168.2.1")}, 16) = 0 … $ strace -f -e connect ping fritz.box … connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.2.1")}, 16) = 0 connect(3, {sa_family=AF_INET, sin_port=htons(1025), sin_addr=inet_addr("192.168.2.1")}, 16) = 0 ping: icmp open socket: … $ strace -f -e connect epiphany … Process 2446 attached Process 2447 attached Process 2448 attached Process 2449 attached [pid 2449] connect(14, {...}, 110) = -1 ENOENT (No such file or directory) [pid 2449] connect(13, {...}, 110) = -1 ENOENT (No such file or directory) [pid 2449] connect(13, {...}, 16) = 0 [pid 2449] connect(13, {...}, 16) = 0 [pid 2449] connect(13, {...}, 16) = 0 [pid 2449] connect(13, {...}, 16) = 0 [pid 2449] connect(13, {...}, 16) = 0 [pid 2449] connect(13, {...}, 16) = 0 [pid 2449] connect(13, {...}, 16) = 0 [pid 2449] connect(13, {...}, 16) = 0 [pid 2449] connect(13, {...}, 16) = 0 [pid 2449] connect(13, {...}, 16) = 0 [pid 2449] connect(13, {...}, 16) = 0 [pid 2449] connect(13, {...}, 16) = 0 [pid 2403] connect(13, {...}, 16) = -1 EINPROGRESS (Operation now in progress) Process 2450 attached Process 2451 attached Process 2452 attached Process 2453 attached Process 2454 attached [pid 2453] connect(18, {...}, 16) = 0 [pid 2453] connect(18, {...}, 16) = 0 [pid 2453] connect(18, {...}, 16) = 0 [pid 2453] connect(18, {...}, 16) = 0 [pid 2453] connect(18, {...}, 16) = 0 [pid 2453] connect(18, {...}, 16) = 0 [pid 2453] connect(18, {...}, 16) = 0 [pid 2453] connect(18, {...}, 16) = 0 … (epiphany does not connect to 192.168.2.1 at all) As far as I understand this your guess is right: firefox tries to connect to fritz.box first, epiphany doesn't. Or am I getting something wrong?
(In reply to Michael Catanzaro from comment #1) > To debug this, I would look at > ephy_embed_utils_normalize_or_autosearch_address(). In particular, I guess > the call to is_public_domain() in ephy_embed_utils_address_is_valid() will > of course fail here. We should figure out how Firefox handles this: I can't > imagine they resolve the name first to see if it works, because that could > be slow.... We used to do that, but we lost it in the WebKit2 migration. I have code to ping a server using libsoup in a private branch that I never finished, I'll look at it. Sometimes it happens the opposite, you try to search for something like std::unique_ptr and URL cannot be shown is what you get.
Do we really need to ping the server? We just need to force a DNS query and get a result. (webkit_web_context_prefetch_dns() is unsuitable since it's not guaranteed to occur and doesn't return a result.)
(In reply to Michael Catanzaro from comment #4) > Do we really need to ping the server? We just need to force a DNS query and > get a result. (webkit_web_context_prefetch_dns() is unsuitable since it's > not guaranteed to occur and doesn't return a result.) Yes, sorry, with ping I didn't mean exactly the protocol, but in general, I think what we used to do was asking for the headers, but I don't remember. We don't need any WebKit API, we can use libsoup directly.
*** Bug 754846 has been marked as a duplicate of this bug. ***
This one should be fairly simple: just use soup_address_resolve_async() [1]. If the host is resolvable, load the page, otherwise do a web search. [1] https://developer.gnome.org/libsoup/2.51/SoupAddress.html#soup-address-resolve-async
(In reply to Michael Catanzaro from comment #7) > This one should be fairly simple: just use soup_address_resolve_async() [1]. > If the host is resolvable, load the page, otherwise do a web search. My bug (bug 754846) should be a separate one, as .local is a valid TLD (unlike .box) so should really be whitelisted in epiphany's regexes (which I couldn't make sense of).
Maybe I'm missing something, but is it really a separate bug? We should get rid of all the regexes and load the page as specified if the host is resolvable, else load the search engine.
(In reply to Michael Catanzaro from comment #9) > Maybe I'm missing something, but is it really a separate bug? We should get > rid of all the regexes and load the page as specified if the host is > resolvable, else load the search engine. I didn't realise your advice in comment 7 was about replacing the whole regex system with that call.
(In reply to Michael Catanzaro from comment #9) > Maybe I'm missing something, but is it really a separate bug? We should get > rid of all the regexes and load the page as specified if the host is > resolvable, else load the search engine. Would that mean that we would search for web pages that don't exist? Like http://thiswebpagedoesntreallyexist.com/ ?
Er... yes... OK, so that's not a good idea....
*** This bug has been marked as a duplicate of bug 663505 ***