Open Bug 479752 Opened 15 years ago Updated 2 years ago

restoring tabs behind a redirecting hotspot loads x identical tabs

Categories

(Firefox :: Session Restore, enhancement)

Product:
Firefox
Component:
Session Restore
Type:
enhancement

Tracking

()

People

(Reporter: rmackenzie, Unassigned)

References

Details

(Keywords: student-project)

Attachments

(1 file)

This is a working (but hacky) implementation of the feature.
26.66 KB, patch
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.6) Gecko/2009020911 Ubuntu/8.10 (intrepid) Firefox/3.0.6
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.6) Gecko/2009020911 Ubuntu/8.10 (intrepid) Firefox/3.0.6

If you open firefox to restore many tabs, as you would when starting up a laptop, and you are behind a hotspot that requires login, all the tabs will load, and each one will ask you to log in.  HTTPS sites will complain about invalid certs.

You proceed to log in, and each tab is still pointed towards the redirected login page.  Sometimes, reloading all tabs will fix, depending on the hotspot. (Some use orriginating website URL in the GET)

Reproducible: Always

Steps to Reproduce:
1. Have multiple tabs open
2. Crash firefox (kill process)
3. Log out of authentication session behind a hotspot. (Cycle power to wireless adapter)
4. Restart Firefox and restore tabs.
Actual Results:  
Each tab loads the login screen.  HTTPS sites complain about cert.

Expected Results:  
There should be a UI that informs the user of limited connectivity.  The user should have the option of logging in first, then loading the tabs and windows from the previous session.

This will require testing the connection to the internet.  This is not a trivial task as simple methods only test for connection to any network.

A system similar to phishing detection where high-availability servers are tested may provide this.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #1)
> *** Bug 471725 has been marked as a duplicate of this bug. ***
Darn, I searched but missed that one.

I'd still like to explore the possibility of this.  I think that the solution of adding a connectivity check will make Firefox a bit more friendly.
This is an important issue and potentially has many solutions.  Personally, I have firefox set to save all tabs on exit and restore on load.  If limited connection occurs at start up I dont think there is a need to load all tabs but rather open one tab with the hotspot login.  Upon successfully connection if multiple tabs are to be restored the restore session page could be displayed allowing the user to pick which tabs to restore. Or all tabs could be restored if the user has that selected as the default action

Limited connectivity could be considered working off-line as there are many similarities.  Both shouldn't allow any new web pages to be loaded as with limited connectivity a forced redirect will just occur.  Limited connectivity occurs when you are associated with an access point (have an IP address).  This check already occurs for work offline mode. In firefox 3.06 if you start firefox with no Internet connection (no ipaddress) then there is a check (appears to be disabled in Minefield as toolkit.networkmanager.disable set to true) with the network manager.  To test for limited connectivity a ping to a high availably server could be sent at this time.  If no response we can assume limited connectivity and proceed as outlined above.
Forehead->Keyboard   Good thought! I always forget about good-ol' ping.

This also can do amazing things to unfinished downloads. Nothing like a partial .iso being transformed into a 3K html document.

Redirection is less of an issue on Windows or Mac systems, as there should be at least one non-firefox browser available to start first and handle the login request. But on Linux, it is often the case that Firefox is all the user will have to work with. (Ubuntu for example) Those users have been losing tabs and being punished since the advent of sessionrestore. They need to open the browser to log in, but opening the browser trashes their sessionrestore.

And there is the issue of URL trashing. Losing the original URL of a page entirely, defeats the entire expectation of a restore system. Most users will be defeated from the moment they find themselves unable to click 'back'.

I agree with #3: Detection and handling of this event are best if covered before the first window even opens. A cheap solution would be switching to offline mode and displaying a pop-up that offers a few simple instructions.
ICMP ping will not work, most hotspots will allow ping through, or transparently redirect it, and answer.
Also, firefox doesn't really deal with ICMP, or anything non-TCP, so that would probably be out of scope.

I was thinking of downloading a pubkey encrypted list of available servers in order to check. This would allow authentication of the server, as well as downloading an up to date list of "availability servers"

I have thrown together some UI pages, I will look at implementing this later.

Ideas?
I think something like this would work.  For this to work generally there would need to be a few servers that would always be online.  I like the idea because receiving the updated server list would mean that there is always one that would be up.  This may create overhead on the mozilla start up time, or were you thinking of having this run only after recovering from a crash.

I have noticed one difference between the stable 3.06 and the new beta and alpha.  When you restore tabs on the beta it restores most of the tabs content from cache (I tested this by closing Minefield, disconnecting the Internet and launching Minefield -- most of the tabs restored without an active ip connection). While on the other hand, 3.06 attempts to load each page again on session restore.

With the above being said, think about what will happen if you need to authenticate to a hotspot.  It appears that you are connected a runtime, yet each of the pages are being displayed from cache.  So the next time you click a link you are forced to the hotspot login.  Sure this fixes the isuue of having a bunch of tabs displaying a login fourm, but it still leaves the user needing to log in one one tab, and possibly confusing them of their current connection status...
Simon Bünzli,
I see you wrote most of the original code.

I'd like to hear your opinion on this bug.

-Rob
(In reply to comment #6)
> I think something like this would work.  For this to work generally there would
> need to be a few servers that would always be online.  I like the idea because
> receiving the updated server list would mean that there is always one that
> would be up.  This may create overhead on the mozilla start up time, or were
> you thinking of having this run only after recovering from a crash.

I agree, having multiple servers makes this a much more reliable solution. As for the overhead, I think that it would likely be sufficient to only do this only when restoring from a crash. Also, you mentioned before that you have Firefox set to save all tabs on exit and restore on load. I don't use this feature, but I'm wondering if you can save your tabs, restart, and then restore those tabs? If so, perhaps the check could also be done for the first instance of Firefox since the system has booted, provided the user has Firefox set up that way.

Additionally, perhaps there could be an option in Preferences to completely disable this check, as it serves no purpose for anyone who does not use wireless.

> With the above being said, think about what will happen if you need to
> authenticate to a hotspot.  It appears that you are connected a runtime, yet
> each of the pages are being displayed from cache.  So the next time you click a
> link you are forced to the hotspot login.  Sure this fixes the isuue of having
> a bunch of tabs displaying a login fourm, but it still leaves the user needing
> to log in one one tab, and possibly confusing them of their current connection
> status...

This may be a naive comment and it's not STRONGLY related to this, but it still applies: is there a particular reason why the user is not notified in any way when a page is loaded from cache? It seems to me that if there was something in the UI that let the user know, it would lessen the level of confusion in situations like this one, among others. I wouldn't suggest an annoying pop up or anything like that, but maybe a little icon.
Could the browser attempt to load the first page in the first tab from online? If there is any redirection, or the document fetched does not resemble the cache, then restore from cache for all open tabs, and display an alert? With puportedly useful sessionrestore coming in 3.1, and hopefully the URL-thrashing lessened, would it be possible to better expose sessionrestore in the event of mass redirection? Say [File]->[Reset to last shutdown]?

This is one of the few good things about Safari. Not good enough for me to take Safari seriously, but by default it loads the homepage at start. If the page is redirected, log in, then use the Restore Previous Session option to get your tabs back.

Additionally, the more aggressive Restore behavior of Firefox 3 nearly guarantees that even if the user crashes the browser in desperation, some of the tabs will have had their URLs changed to the login domain when Firefox is restarted. And since URL-thrashing hasn't been squashed yet, I now no longer have even the 'safe' option of killing Firefox to recover corrupted tabs.
You're basically asking for bug 339678 to be fixed in a user friendly way which is fine, as long as it doesn't introduce anything which could slow startup down (such as pinging a remote server and then having to wait for a timeout until being able to continue).

This could be achieved by observing the first page loads as to whether the loaded pages are redirected to a different eTLD (which should ignore most redirects to login forms happening due to expired sessions/cleared cookies). If this happens, resuming the session could be stopped and all but two tabs be closed: One for the hotspot's registration page and one for a nicer version of about:sessionrestore from which the user can restore the session when she's good to go.

As for the case of the redirection not being detectable (because the hotspot just returns its own page instead of the requested one), that would be mostly bug 345135 in effect once you've reloaded all tabs after having logged in.

(In reply to comment #9)
> then restore from cache for all open tabs

We already restore from cache where we can. Problem is that the cache is limited in size, certain pages request not to be cached to start with (mainly from https sites) and bug 105843 is still waiting to be fixed...

> would it be possible to better expose sessionrestore

That's bug 452772. With Firefox 3.1, you can at least manually enter about:sessionrestore into the address bar and then restore the session again.
Simon, what do you think of Rob's pubkey solution? (Comment 5)
Well, Simon is correct on that. Even jumping technical hurdles, ping is a bad idea. Pubkeys and other lists will add load SOMEWHERE, and as he said perceived startup times are considered important. So observing the behavior of live tabs as they load, would help a great deal. Perceived startup should be minimally impacted (especially on a modern computer where connection is often the only bottleneck), and the load will only be interrupted if something causes that monitor to trigger. If many different domains are turned to the same outside domain, that would be a trigger. If many different addresses are receiving the same page content, that would be a trigger.

Might server flood detection code serve as an example for testing behavior of transferred pages? There are some simple iteration tests, like if 20/20 page requests all received a redirect. If the address is unchanged, maybe Firefox should do nothing if 345135 can be fixed. After all, a firewall may replace a wide range of prohibited pages with the same permission error.
Ok, 
Matt, Tyson and I have come up with a potential solution.  We'd like to hear the community response on it.

First, it should be known that this was undertaken as a project for a CMPT class focusing on open source development at SFU.

Ok, so I think the best way to present our ideas is through this Prezi link : http://prezi.com/30043
This (I hope) shows the system we have designed.  

We have not only thought this out, we have a working implementation.  Here is the diff file, made using hg diff

http://robmackenzie.com/connectivitycheck.diff

Now, this isn't a final solution, as if you'll notice, the full implentation is not in the diff, only a check to a static server.  It also uses an HTTP get through an XMLhttprequest XPCOM.  I'd like to move this over to a direct TCP connection, as then we could control timeouts etc.  In it's current version though, it does work, rather quickly too.  

While the course is over, I wouldn't mind sticking around and following this through.  Looking forward to responses on this.
Couple general process comments...

> First, it should be known that this was undertaken as a project for a CMPT
> class focusing on open source development at SFU.

Great, marking as such.

> We have not only thought this out, we have a working implementation.  Here is
> the diff file, made using hg diff
> 
> http://robmackenzie.com/connectivitycheck.diff

Take your diff (hg diff -p -U 8) and attach it to this bug, marking it as a patch.  You might consider naming it [WIP], in order to indicate to others that it's still a Work In Progress.

> While the course is over, I wouldn't mind sticking around and following this
> through.  Looking forward to responses on this.

After your patch is there, good to request review (i.e., r?<bugmail>) from someone who can review patches for this.  This way you can get comments from those who will be able to approve the patch in the end.  Perhaps zeniko@gmail.com or dietrich@mozilla.com.

Great to have you working on this, and I hope you do follow this through.  It's a great idea, and really rewarding seeing your work ship in Firefox.
Keywords: student-project
The xmlHTTPrequest should be replaced with a TCP connection, 
The code for downloading and updating server lists needs to be added, right now it's hardcoded to a friend's test server.

I've put this up so as to get suggestions on the overall idea.
(In reply to comment #15)
> Created an attachment (id=374027) [details]
> This is a working (but hacky) implementation of the feature.

This will delay startup when resuming the session with a slow connection, as you have to wait until getting either an answer or a timeout. Considering that other options are available (cf. e.g. comment #10), I'd not pursue this solution unless nothing faster is doable.

A second issue is that resuming a session will behave differently than either opening multiple homepages or starting up blank and the opening a bookmark group (in both cases you'd still get multiple authentication pages). That'd however mean that your code would rather have to live in browser/tabbrowser than in SessionStartup.
Let me suggest a solution: for pages reloaded when a session is restarted, if their titles are changed, we'll optionally close them and put in a list similar to that in about:sessionrestore
Should this be marked WONTFIX given that we no longer load all tabs by default at startup?
Yes, it should.
I'm not sure about WONTFIX, it seems like there are still things that we could do to improve captive WiFi portal detection. But I agree that it's lower priority now that we don't immediately restore sessions by default.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: