I am soliciting feedback on the idea: is this something that Mozilla would consider adding to Firefox?
Currently, the only way that I'm aware of to determine when a user has closed all related windows/tabs is by having the browser poll the server at a regular interval, and once the polling stops, the server knows the user is no longer actively using the site.
Thanks,
- Bil
[1] "When closing the browser" thread:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-December/thread.html#17764
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-April/thread.html#19406
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-June/thread.html#20150
[2] http://wiki.whatwg.org/wiki/RelExtensions
[3] http://wiki.whatwg.org/wiki/LogoutRelExtension
Was it accepted by the HTML5 specification? It doesn't sound like a
particularly useful feature to me, considering that this seems to be mostly
a solved problem.
> Currently, the only way that I'm aware of to determine when a user has
> closed all related windows/tabs is by having the browser poll the server
> at a regular interval, and once the polling stops, the server knows the
> user is no longer actively using the site.
Why exactly do you need to know when the user has closed all related
windows/tabs? How is this better than just timing out the user's session if
they haven't made a request in 30 minutes, and doing an occasional poll if
the user is in a long-running task such as editing a document?
The spec says same-origin, but doesn't define whether that means eTLD+1 or
actual specific origin. What kinds of loads would "prevent logout"? Would
images loaded as <img>? Images loaded as documents? Frames loaded in another
site's toplevel window? PDFs, videos, or other non-HTML documents loaded in
a browser window (i.e. via the Acrobat plugin)?
Must the logout URL be same-origin with the site?
My initial reaction is that we would not implement this feature, but let
sites solve this problem, if it must be solved, using existing technologies.
--BDS
I'm not sure if the "when all related windows/tabs are closed" part is
interesting (eg, what to do when that happens because the browser
crashed, or the browser doesn't support the rel extension?).
OTOH, there has been some brainstorming around how to improve identity
and logins in general. Form-based password management is basically a
hack, so it would be nice to have a more formal syntax to tell the
browser how to login and logout from the site. We can (in theory) mostly
do this with HTTP authentication, but logins based on forms and cookies
are far more common.
Justin
HTML5 doesn't accept nor reject rel extensions, it allows anyone to reserve a rel extension by editing the HTML5 wiki. Ian encouraged me to write a spec and get vendor support:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-June/020150.html
> It doesn't sound like a
> particularly useful feature to me, considering that this seems to be mostly
> a solved problem.
You're right, it's mostly solved. You just have to accept that the user has to be idle for X minutes or that the browser has to check in with the server using a small delta between requests (significant traffic). The type of problem I'm trying to solve is one like this: A web application allows the user to hold a resource while browsing the site (e.g. concert tickets, airline seats, conference room, inventoried items). The web application wants to release the resource as soon as possible should the user leave the site. How does the server know when the user leaves the site? The current method is it makes the assumption that if the user is inactive for X minutes, then log out the user and release the resources. But that creates a lag of X minutes. If it's a hot inventory item, that means it's unavailable to sell to someone else for X minutes.
>> Currently, the only way that I'm aware of to determine when a user has
>> closed all related windows/tabs is by having the browser poll the server
>> at a regular interval, and once the polling stops, the server knows the
>> user is no longer actively using the site.
>
> Why exactly do you need to know when the user has closed all related
> windows/tabs? How is this better than just timing out the user's session if
> they haven't made a request in 30 minutes, and doing an occasional poll if
> the user is in a long-running task such as editing a document?
This feature isn't for every site, only sites that wish to equate the user action of closing all windows/tabs with the user being logged out. I anticipate that financial institutions would be interested in knowing when their users have left their site. I believe most financial institutions today have a short expiration, then query the user when it's about to expire to see if they want to prevent logging out.
FWIW, if Firefox expired transient cookies and HTTP Authentication when all the related windows/tabs were closed, I don't think we'd need this proposal.
> The spec says same-origin, but doesn't define whether that means eTLD+1 or
> actual specific origin. What kinds of loads would "prevent logout"? Would
> images loaded as <img>? Images loaded as documents? Frames loaded in another
> site's toplevel window? PDFs, videos, or other non-HTML documents loaded in
> a browser window (i.e. via the Acrobat plugin)?
All good questions, I don't have any answers yet. I first wanted to see if Firefox would consider supporting it before spending too much time on it.
> Must the logout URL be same-origin with the site?
Yes, the spec already requires this, although it may be poorly worded: "The href attribute must point to the same origin as the current document."
> My initial reaction is that we would not implement this feature, but let
> sites solve this problem, if it must be solved, using existing technologies.
Thanks for the feedback!
- Bil
Yes, the fallback method would be a session expiration of some kind.
> OTOH, there has been some brainstorming around how to improve identity
> and logins in general. Form-based password management is basically a
> hack, so it would be nice to have a more formal syntax to tell the
> browser how to login and logout from the site. We can (in theory) mostly
> do this with HTTP authentication, but logins based on forms and cookies
> are far more common.
It may be this problem is better solved by a group working on new UA authentication methods.
- Bil