Working on Firefox front-end code, I am often reminded of Nicholas’ excellent post on people’s experiences and how those experiences shape their opinions.
The most recent example concerns the beforeunload event and the resulting dialog.
On the one hand there are people who see it as the bane of a usable web. They mostly encounter it when it is abused by malicious websites to trap users on a page they don’t want them to leave, and so they view it as a misfeature that should have been removed from the relevant specs 10 years ago. Websites shouldn’t be able to keep a tab open at all! They honestly and sincerely see no reason why on earth Firefox (and most other desktop browsers) still support it.
On the other there are people who see it as critical web infrastructure to ensure users can’t accidentally close a tab/window while in the middle of a task, causing data loss, and for that reason they honestly and sincerely see no reason why we’re even talking about getting rid of it. “Even” Facebook and Google Apps, who otherwise have decent facilities for saving drafts etc., will use it in some cases.
Even when this discrepancy in experience and their resulting opinions is pointed out, people who hold opinions on the extreme end of this spectrum seem reluctant to accept that really, there might be both pros and cons involved here, and a solution is not so straightforward as either believed.
If/when they do, the solution offered is usually “make it a preference”, with resulting debate about what the default should be (NB: in this case, such a (hidden) preference was already added). However, this is not what we prefer doing when working on Firefox, we historically haven’t, and still don’t.
I’d be interested if people have suggestions on how we could concretely address both usecases in the example I used, in a way that makes life better for both groups of users. For the latter, note that the event causes other technical difficulties even when not used for ‘trapping’ users, and that mobile browsers have already started disregarding it in some cases.
At this point, the best plan I know of is not showing a dialog when closing a single tab, perhaps while keeping the dialog for application/window closes and navigation. (For concrete followups regarding this particular issue, please consider writing to firefox-dev instead of commenting here.)
However, finding a solution for “beforeunload” and its dialog doesn’t solve the more general problem: how do you bridge the gap in the general case and explain why we are not “just” doing what seems “obvious”? How do you turn the fierce disagreement into a constructive solution-oriented discussion?
> see no reason why we’re even talking about getting rid of it
Are you?
Modal dialogs is something developers use because it is easy and we are lazy. In particular the “Are you sure?”-style dialogs is just a way for the developers to be able to make it the users fault if something goes wrong. It is probably better UI to do the action immediately and giving the user the option to undo (perhaps with a notification as Gmail does). Since there might be a lot of state and even network accesses in a tab, enabling undo would probably mean not closing it, but just hiding it (bu that is an implementation detail).
We’re talking about adjusting if/when/how the “beforeunload” dialog is shown in some of the bugs linked from my post, yes.
We already support “undo close tab”, but it’s not done by “hiding” the page. We do tell the page it unloaded immediately when you close it. So depending on page architecture that can still lose you information. Other people have also pointed out that there can be cases like live streaming/gaming/webrtc where you irretrievably lose information if the tab stops existing / being visible even for a fraction of a second, quite irrespective of how you restore it.
Full “undo” for closing a tab is complicated because of that, but also because people do expect that closing tabs releases the memory etc. associated with it. Likewise, pages expect particular events (pagehide, beforeunload, unload) and sometimes do (important) things in those events. So “just” hiding a tab is a lot more complicated than it sounds. If you break off the JS in the otherwise invisible tab, that will break pages. If you don’t do that, and the page can still show, say, desktop notifications, or influence other windows it opened (because it has JS references to them if they were opened using window.open), then that is obviously strange. If you send the relevant events, often page state is altered in such a way that a clean “undo” is no longer possible (that is, pages would never expect to be “resuscitated” after an “unload” event), and indeed those events themselves can be problematic (as noted in the post).
Of course, things get more complicated than that still when it is, say, the last tab in a window, and/or the last window in the application. Persisting the complete state of a tab (including pending timeouts, requests, events, etc.) to disk in a way transparent to the page isn’t something that is currently possible (and would be a huge amount of work to get right). That’s a lot of stuff to work on for an “implementation detail”. 🙂
Okay, I missed those, I only hovered the first few links and none of where bugzilla links and from the context the others didn’t seem as if they linked to current discussion.
“Full “undo” for closing a tab is complicated […]”
Your response nicely illustrate that laziness I mentioned 😉
I read your post as wanting to explore the user experience. That is, what would the ideal experience be (independent of difficulty), as there is no reason working hard to achieve something if the ideal solution is in another direction.
But with regards to implementation, I agree that the current “undo close tab” functionality is broken. That is why I proposed hiding the tab. I believe there already some “de-prioritization” going on for non-active tabs (i.e. events — e.g. requestAnimationFrame, timers — are stopped, garbage is collected). So if the right experience is to immediately remove the window and add a notification perhaps with the text returned by beforeunload and an undo button (I suspect that few users currently know how to undo closing a tab or that it is possible). That “de-prioritization” could be extended such that e.g. any waiting network requests would be paused and already started connections would be throttled (as it might not be possible to restart them) to the slowest speed that can keep the connection alive to conserve bandwidth. After a minute or two the document could be killed completely. There is already (or was) some “fast-back” functionality (inspired by Opera) for keeping pages around so the user can go back fast (see http://shallowsky.com/blog/tech/web/firefox-fast-back.html ) and the “undo closed tab” seem quite similar.
“Persisting the complete state of a tab […] to disk in a way transparent to the page isn’t something that is currently possible”
Nobody suggested that. Partly because active network connections do not persist.