Caveats: This may have to do with my specific ISP, but here are STR I'm on FF 50.0.1 (release) on a 2016 MBP - In Awesomebar type the word 'toe' or any other one word string (no spaces) - hit enter result: I see a notification (see attachement) asking me if i want to go to 'toe', clicking yes takes me to my ISP's search UI and I can no longer search for toe through the awesomebar without being redirected. expected: I see a search results page with no notification. So (a) this is bad UX, we should fix it. My understanding is that this behavior is intended to catch intranet related searches, but I'm getting hammered with pretty constantly right now. and (b) once i've said 'yes' is there any way for me to reverse that decision.

this problem occurs regardless of search suggestions

this problem occurs regardless of search suggestions being enabled or disabled

Did we not consider this case when this got added in bug 693808? Or is something not working right? Seems surprising, because this is a not-uncommon ISP thing, but I also don't remember hearing similar reports of this in the time since that landed. Looks like we did add a pref to restore the previous behavior (to basically ignore the search and take you wherever DNS says to go), but what we'd want here is a way to ignore DNS and always do the search (without showing the infobar, which is the annoyance here). Better still would be to have the browser figure this out automagically. I suppose we could kick off a 2nd DNS request for a random string (which shouldn't resolve), and suppress the infobar if it does resolve?

(In reply to Justin Dolske [:Dolske] from comment #3) > Did we not consider this case when this got added in bug 693808? We did (or at least, I thought about it when I started taking over that bug, cf. bug 693808 comment 38), but it's not a trivial problem (see comments on bug linked below) and on balance it seemed sane to ship 693808 without fixing this case. > Seems surprising, because this is a not-uncommon ISP thing, but I also don't remember hearing similar reports of > this in the time since that landed. bug 728670 is relevant. Likewise, I don't recall anything / see anything in the dep tree. Though, looking at bug 1180329 in more detail, it's possible that is the same issue (but hard to be sure given the reporter never responded). > Looks like we did add a pref to restore the previous behavior (to basically > ignore the search and take you wherever DNS says to go), but what we'd want > here is a way to ignore DNS and always do the search (without showing the > infobar, which is the annoyance here). Better still would be to have the > browser figure this out automagically. I suppose we could kick off a 2nd DNS > request for a random string (which shouldn't resolve), and suppress the > infobar if it does resolve? Specifically, if it resolves to the same IP... yes, we could do this. I don't know how expensive it would be and how likely it is to cause issues per comments in bug 728670. You'd want to cache the DNS response to avoid doing 2 DNS lookups for every time this happens, and then invalidate the cache when the network changes. Nihanth, seems like you have some background here given we now have a captive portal service etc. Do you know if we already know if DNS is hijacked?

(In reply to :Gijs from comment #4) > (In reply to Justin Dolske [:Dolske] from comment #3) > > Did we not consider this case when this got added in bug 693808? > > We did (or at least, I thought about it when I started taking over that bug, > cf. bug 693808 comment 38), but it's not a trivial problem (see comments on > bug linked below) and on balance it seemed sane to ship 693808 without > fixing this case. > > > Seems surprising, because this is a not-uncommon ISP thing, but I also don't remember hearing similar reports of > > this in the time since that landed. > > bug 728670 is relevant. Likewise, I don't recall anything / see anything in > the dep tree. Though, looking at bug 1180329 in more detail, it's possible > that is the same issue (but hard to be sure given the reporter never > responded). > > > Looks like we did add a pref to restore the previous behavior (to basically > > ignore the search and take you wherever DNS says to go), but what we'd want > > here is a way to ignore DNS and always do the search (without showing the > > infobar, which is the annoyance here). Better still would be to have the > > browser figure this out automagically. I suppose we could kick off a 2nd DNS > > request for a random string (which shouldn't resolve), and suppress the > > infobar if it does resolve? > > Specifically, if it resolves to the same IP... yes, we could do this. I > don't know how expensive it would be and how likely it is to cause issues > per comments in bug 728670. You'd want to cache the DNS response to avoid > doing 2 DNS lookups for every time this happens, and then invalidate the > cache when the network changes. > > Nihanth, seems like you have some background here given we now have a > captive portal service etc. Do you know if we already know if DNS is > hijacked? Interesting. To answer your question, the captive portal service doesn't know anything about DNS, it only checks if a specific URL is getting hijacked. Seems like an ISP wouldn't hijack an actual URL, i.e. the CPS won't have a clue as long as the response to our canonical URL (http://detectportal.firefox.com/success.txt) is as expected.