664266 - When I connect to a network that uses a captive portal, Firefox does not show me the login screen

Status: RESOLVED DUPLICATE of bug 562917

(Core :: Networking, defect)

Description

[Stormy Peters]

Attachment: Firefox error message that displays instead of authentication page

When I connect to a network that uses a captive portal (authentication through a web page), Firefox does not show me the login screen. I open Safari, get the login screen, go through the authentication process and then I can use Firefox.

This has happened at numerous airports, hotels and Mozilla.

It's happened on Firefox 4 and Firefox 5 beta.

Attached are the screen shots of the error message Firefox gives me and what Safaris shows me.

Comment 1

[Stormy Peters]

Attachment: The login screen I get with Safari.

Comment 2

[Matthias Versen [:Matti]]

How about a packet trace with a working and from a not working example ?
I don't understand how this can be Geckos fault.
Such portals should do a DNS based redirect to their login page.
Have you already tried to enter a URL that is guaranteed to not be cached by either Gecko or the OS DNS cache ?

Comment 3

[Stormy Peters]

I always do a google search to see if I'm on. 

I don't know whose "fault" it is but it always works with Safari and never works with Firefox.

How do I do a packet trace?

Comment 4

[Matthias Versen [:Matti]]

I describe how many of those captive portal redirects are working.
The internet works with IPs and not names. You enter google.com as URL and Gecko asks the OS for the IP number for this name. The OS itself asks the configured DNS server which is mostly a DNS server or forwarder running on the local router. The answer is going all the way back to Gecko (example: 209.85.148.99).
This name to IP resolving takes time and it would be very slow to do that for every resource in the page again. The os caches those DNS answers and Gecko also manages it's own DNS cache to avoid the slowdown.
Those portals are doing most likely this to get you to your login page:
The DNS server on the router doesn't respond with a IP for a google server, it responds with their routers http server IP that contains the portal page.

What I guess what happens in your case is this:
You still have Firefox open and the google IP is in the Gecko DNS cache.
You suspend your laptop and open it again at the new location with the wifi portal. You enter google and instead of asking for the router for the IP for google, gecko uses the cached IP and tries to connect to it.

Safari seems to only use the OS cache that seems be cleared with a network change or you didn't had it open before suspending your laptop.

>I don't know whose "fault" it is but it always works with Safari and never works with Firefox.
We have to find the technical reasons for this problem and I can't try it myself because I don't have the problem. I should ask mozilla for more summit invites :-)
There are many guesses on my side: suspended laptop, Firefox still open during suspend, DNS based redirect and not injected html, DNS caching.

We would now that my guesses are right if it works if you enter an unknown hostname and if you can confirm that your suspend your laptop while Firefox is still open.

Comment 5

[Stormy Peters]

Firefox is always open when I suspend my laptop.

So as a next step, would you recommend that I go somewhere I know I'll have this problem and type in a url in Firefox that I've never visited?

Comment 6

[Matthias Versen [:Matti]]

>So as a next step, would you recommend that I go somewhere I know I'll have this 
>problem and type in a url in Firefox that I've never visited?

A page you haven't visited shortly before suspending the laptop is enough but you can use for example http://example.com to be sure.

Comment 7

[Stormy Peters]

It works as I would expect if I go to a page I have never been to before. But does not work if I try to go to a page I've been to. In the other browsers I've tried (Google Chrome, Safari) it works as expected in both cases.

Comment 8

[Matthias Versen [:Matti]]

moving to Networking, we should clear the DNS cache either after a network change or after resume/hibernate.

Comment 9

[Patrick McManus [:mcmanus]]

(In reply to comment #8)
> moving to Networking, we should clear the DNS cache either after a network
> change or after resume/hibernate.

dns times out quickly.. in the past this has been due to persistent connections hanging around.

we should clear those after a resume if we don't already do that.

in the meantime - 628561 (not yet landed) should make a force-reload clear them out. (something people tend to do reflexively when stuff like this isn't starting up right.) maybe watch that bug and retest?