Without being fully aware of the issues here I will suggest that expired sessions is only the beginning of what can go wrong. We've been hunting "Unexpected Network Change" errors only to find that it is a chronic problem that depends on many layers of dynamic behavior beneath the ajax call.

https://github.com/WardCunningham/Smallest-Federated-Wiki/issues/433
https://code.google.com/p/chromium/issues/detail?id=166593

I think there are four groups of errors, based on what the user can do about it:

1. intermittent errors in the AJAX request (network errors, server being busy)

2. bugs

3. session timeout - user needs to log in again

4. localstorage errors (strict security settings or quota exceeded, or even no localstorage support at all)

1. and 2. could be covered by something like "there was an error, please retry and report it if it persists". 3. is very rare and will cease to be at the next page load so it's probably OK to ignore it.

I'm not sure about 4 - that's something that needs user intervention, and a source of complaints (there have been reports that it is impossible for anons to disable Media Viewer, which I suppose is caused by this). Localstorage settings are a poweruser feature though, not sure how to communicate about them.

_______________________________________________
Multimedia mailing list
Multimedia@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/multimedia

On Thu, Oct 16, 2014 at 05:09:15PM +0200, Pau Giner wrote:

If there can be an error we need to be prepared to deal with it.
For designing a proper solution I need some more information. Which kinds
of errors can be produced and at which point of the workflow? Is there a
way to solve them without user intervention? Is there some information we
can provide to help the user to solve them? Will retrying later be a likely
way to solve the issue?

I think the only *expected* problem we can have will be expired session.
We'd need to load the page while logged in, then have it open for many
days (30?), then the user tries to disable the viewer. That would cause
a token error (like we've seen in UploadWizard) and the user would need
to log in again.

Unexpected errors include bugs in how we construct the request, bugs in
the API, network errors based on the user loading a page and disconnecting,
but we can usually get a sane message from any of those errors automatically.

From the process of disabling, the only error point I can imagine is
clicking on the "disable/enable" button and the action not taking effect
because the place where we store such info fails to do so (I don't know if
that is an external server). For this kind of error, we can just inform
using a standard MediaWiki notification bubble with some message along the
lines of "It was not possible to disable Media Viewer due to some technical
difficulties. Please try again later." and keep the panel opened so that
the user can try again. In any case, we should not show the confirmation
popup if the action had no effect. In any case, I'm making here some
assumptions since I don't know the internals of the process.

This means not getting any additional details from users who report the
issue - inferior to our current error reporting, which gives us some
error message along with the failure notification.

A standard mw.notify bubble wouldn't work, though - the reason we're
thinking about this at all is that the disable dialog is overlapping the
notifications as it is.

--
Mark Holmquist
Software Engineer, Multimedia
Wikimedia Foundation
mtraceur@member.fsf.org
https://wikimediafoundation.org/wiki/User:MHolmquist
_______________________________________________
Multimedia mailing list
Multimedia@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/multimedia