>So, my question is how can Firefox know that login page address?

It doesn't, actually.

Your ISP uses a technology known as a [*Captive Portal*](https://wikipedia.org/wiki/Captive_portal). Captive portals work by "somehow" hijacking the browser's HTTP request and re-directing it to the login portal.

This "somehow" can be achieved in different ways, for example 

* HTTP Redirect
* ICMP Redirect
* DNS Hijacking

Your browser, in turn, tries to detect this "hijacking" by trying to retrieve a well-known web page and checking whether the response they get back is the response they are expecting or something else. Here are some examples of pages that such "hijacking detection systems" use:

* http://captive.apple.com/ (Apple)
* http://msftconnecttest.com/ (Microsoft)
* http://connectivitycheck.gstatic.com/generate_204 (Google)
* http://detectportal.firefox.com/success.txt (Firefox)

The Google one gives a hint as to how it works: The webserver will respond with an [HTTP 204 *No Content* status code](https://wikipedia.org/wiki/List_of_HTTP_status_codes#2xx_Success). A captive portal, however, *will* return content (otherwise it would be useless) and therefore never answer with a 204 status code. Most likely, it will use a [307 *Temporary Redirect*](https://wikipedia.org/wiki/List_of_HTTP_status_codes#3xx_Redirection) to tell the browser to fetch a different URI (the URI of the captive portal login page).

The other ones use a small document with well-known content instead (e.g. Apple's simply contains the word "Success").

The hijacking detection doesn't have to be performed by the browser, actually. Most modern devices will automatically run this "captive portal hijacking detection" automatically whenever they connect to an open WiFi and automatically pop up a dialog allowing you to go to the captive portal, without you having to explicitly open up your browser and visit some web page.

The reason for this is that in the modern Internet world, a browser is not necessarily the first app a user would be trying to use the Internet with. It could be the Facebook client, WhatsApp, or email client, for example.

Note that I used the term "hijacking" deliberately. These techniques are actually basically performing a *Man-in-the-Middle attack*. (The difference being that a "real" attacker would try to redirect you to a website that looks exactly like the one you wanted to visit and trick you into entering your username and password on the fake website.) Hence, these techniques only work as long as you are trying to visit an "insecure" website, i.e. a website that does not use [SSL/TLS](https://wikipedia.org/wiki/Transport_Layer_Security) (i.e. no `https://`), does not use [*HTTP Strict Transport Security (HSTS)*](https://wikipedia.org/wiki/HTTP_Strict_Transport_Security), and the likes.

If you try to visit Facebook or SuperUser, for example, your browser will automatically use an encrypted, authenticated connection, and when the captive portal tries to redirect the browser to the login page, the browser will detect this manipulation and throw an error. Normally, this is exactly what you want, but in this case, it will prevent you from logging into the captive portal and thus from using the Internet.

If you ever run into problems where you are connected to the WiFi, but your apps show errors or load indefinitely, the reason is almost certainly that for some reason you are not logged into the captive portal. Maybe you didn't see the notification popup, maybe the detection failed, there can be many reasons.

In this case, you can solve the problem by visiting a website that you *know* is "insecure", i.e. doesn't use HSTS, SSL/TLS, or HTTP/2.0 (which requires TLS). The above-mentioned URIs should do the trick, but there is actually a website which some nice people have put up that serves exactly this purpose, and whose URI is easy to memorize: http://neverssl.com/.