Last modified: 2014-08-17 11:09:24 UTC
I click on an image. I'm in an unsupported browser (iceweasel 3.5) Expected behaviour: * Go to image page Actual behaviour: * Scroll to top of page * Notice pops up "Error loading MediaViewer: One or more dependencies failed to load"
That is a lot more graceful than the empty black screen you would have seen a week ago :) In general, we only support the current version of Firefox/Chrome since the overwhelming majority of their userbase updates regularly, and behavior on older browsers can be sketchy. This error comes from ResourceLoader, though, and I cannot think of any reason how our code could influence whether or not a module loads. Also, I don't see how we handle a loading error more gracefully, although we could do without the scrolling, but that might be unrelated to this bug - see https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/439 (must be a side effect of the bootstrap module messing around with the CSS styles of the body, given that the main app is not even loaded in this case and it still happens)
As for going to the file page directly, we have https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/400 about that, but I am not a fan. That makes very hard to understand what is happening (some images are not handled by MediaViewer, such as article maintenance template icons, and clicking on those takes you to the image page - if errors did that too, you could never be sure which case it was) and very hard for us to correct error details (we display the main error message, and log more details on the console; both are lost when the user navigates away). Maybe we could mark the image on error, so that another click on it does take you to the file page?
(In reply to Tisza Gergő from comment #2) > As for going to the file page directly, we have > https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/400 > about that, but I am not a fan. That makes very hard to understand what is > happening (some images are not handled by MediaViewer, such as article > maintenance template icons, and clicking on those takes you to the image > page - if errors did that too, you could never be sure which case it was) > and very hard for us to correct error details (we display the main error > message, and log more details on the console; both are lost when the user > navigates away). > > Maybe we could mark the image on error, so that another click on it does > take you to the file page? From a user prespective, i doubt they care very much if an error occured. They just want to get to the copyright/description/etc info. If we want to know for debugging purposes, couldnt we use something more subtle e.g. redirect to image page but with ?mediaviewererror on the end of the url, so people debugging could distinguish.
If the user does not realize that a bug has occurred, they won't report it and it won't get fixed. https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/127 would help somewhat but still does not necessarily make it a good idea to disable error reporting, especially in the pilot period.
Change 130272 had a related patch set uploaded by Gergő Tisza: Do not handle clicks if MediaViewer could not be loaded. https://gerrit.wikimedia.org/r/130272
Change 130272 merged by jenkins-bot: Do not handle clicks if MediaViewer could not be loaded. https://gerrit.wikimedia.org/r/130272
Patch was merged a while ago - is there more work left to do here (if yes: please reset the bug report status to NEW or ASSIGNED), or can you close this ticket as RESOLVED FIXED?
No reply to comment 7 - assuming this bug is FIXED. If that is not the case: Please reopen and elaborate what is left to do here to get this report fixed.
