The Tunisian government recently took advantage of Facebook's insecure login page to steal passwords for _everyone in the country_: http://blog.jgc.org/2011/01/code-injected-to-steal-passwords...
Protocol-relative URLs may be useful while migrating to HTTPS, but should not be needed long-term. All content should only be served securely.
Once a site is fully functional over HTTPS, adding the HSTS header is an important last step to further mitigate active attacks. http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
A) Keep a running counter between the server and client. B) If, at any point, there are two active sessions both associated with the same user login, delete both sessions (thus logging out both the legitimate user and the attacker).
Session hijacking is still possible with this method, but only for the duration of one request (as long as you, the legitimate user, remember to log out at the end).
The main disadvantage is that if the request or response gets messed up, the session will be lost. Even if someone does something as simple as click a link twice before the response comes back, the session will be lost. So, yea, kind of a major usability drag...
Although... you could probably eliminate most lost session situations by using the counter method and allowing some leeway in it (say 2 or 3 requests off) to take into account double link click scenarios. That might be a good compromise...