I click on an image. I'm in an unsupported browser (iceweasel 3.5)
Expected behaviour:
Actual behaviour:
Version: unspecified
Severity: normal
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.
Change 130272 merged by jenkins-bot:
Do not handle clicks if MediaViewer could not be loaded.
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.