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 On Oct 16, 2014, at 8:23 AM, Mark Holmquist <[email protected]> wrote: > 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 > [email protected] > https://wikimediafoundation.org/wiki/User:MHolmquist > _______________________________________________ > Multimedia mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/multimedia _______________________________________________ Multimedia mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/multimedia
