Page MenuHomePhabricator

Make MediaViewer error reporting link useful or remove it
Closed, ResolvedPublic

Description

Per @Aklapper in T109240#1556824:

So users are pointed to some random page (either Phabricator or on-wiki) to "report the issue" (without any hints how to do that in an effective way), and without any automatic passing of e.g. the problematic image URL or without showing or even passing any actual error message?
I don't think that helps anybody. Neither reporters nor editors.
Wherever a feedback venue is it should be where someone (developers) actually takes a look (and with (automated?) instructions how to provide sufficient information for developers). But if noone takes a look it does not matter if it's Phabricator or a wiki page (see the depressive UW feedback page example on Commons) and I'd rather disable such feedback links entirely instead of giving users a fake feeling that someone looks at their feedback.

The current error page looks like this, and the reporting URL just takes you to a new task form in Phabricator with only the project field filled out.

One option is to just get rid of it. Another one is to add error details; the error message can be added easily, but for reasons outside MediaViewer, it is rarely helpful (e.g. connection errors tend to just say 'http'). URL and browser UA are also easily added but could be a privacy issue. We would also want to show some explanation on how to write meaningful error reports. Also, the majority of users don't have a Phavbricator account and are redirected to the OAuth registration process; we would have to verify that pre-filled form fields do not get lost when that happens.

See also T101855: Improve MediaViewer error reporting on image load failure

Event Timeline

Tgr created this task.Sep 1 2015, 9:11 PM
Tgr updated the task description. (Show Details)
Tgr raised the priority of this task from to Needs Triage.
Tgr added subscribers: Tgr, Aklapper.
Restricted Application added a project: Multimedia. · View Herald TranscriptSep 1 2015, 9:11 PM
Tgr updated the task description. (Show Details)Sep 1 2015, 9:21 PM
Tgr set Security to None.
Restricted Application added a subscriber: Matanya. · View Herald TranscriptSep 1 2015, 9:21 PM
Tgr added a comment.Sep 1 2015, 9:24 PM

CC WMF-Legal. Is it OK to put private data like user agent and current URL into a Phabrictor form when the user clicks "report" on a Media Viewer error screen? The user would still have to click "Save" in Phabricator before anything gets stored.

Jdforrester-WMF triaged this task as Low priority.Sep 4 2015, 6:49 PM
Jdforrester-WMF moved this task from Untriaged to Backlog on the Multimedia board.

Mass-removing the Multimedia tag from MediaViewer tasks, as this is now being worked on by the Reading department, not Editing's Multimedia team.

Tgr added a comment.Oct 14 2015, 5:41 PM

@Aklapper can you help move this forward? I can submit a patch for it but I don't have the time to figure out what conditions should be met so that this is legally/ethically OK, and who should approve those conditions.

I cannot comment on legal stuff but I'm basically wondering if one could link to https://www.mediawiki.org/wiki/How_to_report_a_bug

Tgr added a comment.Oct 15 2015, 5:35 AM

Of course in the glorious future users just need to report the Sentry error token and Sentry takes care of recording all error details in a privacy-aware way :)

It will take a long time to scale Sentry up to a level where it can handle the traffic from all users who see an error, but handling it from those who report it should not be problematic. I wonder if we could make the error page hold back the report and only do it when the user clicks on the report link.

Change 247969 had a related patch set uploaded (by Gergő Tisza):
Add some error details to bug report

https://gerrit.wikimedia.org/r/247969

Tgr added a comment.Oct 22 2015, 5:06 AM

A sample error report looks like this:

**Details of the error are atteched to the report, which will be publicly viewable. If you are not comfortable with that, you can edit the report below and remove all data you don't want to share.**


Error details:

error: could not load image from http://127.0.0.1:8080/images/thumb/5/5e/Zonotrichia_atricapilla_-British_Columbia%2C_Canada-8.jpg/1280px-Zonotrichia_atricapilla_-British_Columbia%2C_Canada-8.jpg
URL: http://127.0.0.1:8080/wiki/MediaViewerE2ETest?debug=1#/media/File:Zonotrichia_atricapilla_-British_Columbia,_Canada-8.jpg
user agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.85 Safari/537.36
screen size: 1600x900
canvas size: 1520x703
thumbnail size: undefinedxundefined

This is OK with legal. Thanks!

Change 247969 merged by jenkins-bot:
Add some error details to bug report

https://gerrit.wikimedia.org/r/247969

Change 249314 had a related patch set uploaded (by Gergő Tisza):
Add some error details to bug report

https://gerrit.wikimedia.org/r/249314

Change 249314 merged by jenkins-bot:
Add some error details to bug report

https://gerrit.wikimedia.org/r/249314

Jdlrobson closed this task as Resolved.Oct 28 2015, 12:12 AM
Jdlrobson claimed this task.
Tgr reopened this task as Open.Dec 23 2015, 11:45 PM

Reopening, these reports are still useless. Having all the information about resolution and whatnot is nice, but it does not tell what the problem is and apparently it makes the reporter even less inclined to put in the effort of maybe describing their problem in a sentence or two. Or maybe the interface leads them to think that this is something like the OS crash reports where user input is not really expected.

To add insult to injury, the error reporting link is shown for problems that could be caused by network problems (and as such are completely beyond our ability to fix or even diagnose), and we don't collect any network information (not sure if there is even a way to do so) so we have no way of telling apart real problems from users having a crappy router or whatnot.

Some options:

  • just get rid of error reporting. That will probably mask some genuine errors (e.g. T115563 has seen a slew of similar error reports from many different users in a very short period of time, which is very unlikely to be coincidental, so there was probably something wrong on our side), but then the information currently collected is not enough to do something about those errors, anyway.
  • make it very clear that they need to describe the problem and stay in contact. Maybe show a dialog when one clicks on the reporting link, with some explanation of what a good error report should contain and something like "please don't submit an error report unless you can commit to answer some follow-up questions".
  • collect more data and/or only allow reports when we have meaningful data? E.g. for javascript errors the error message would be more useful, but then there are better ways of collecting javascript errors than via user reports.
Tgr updated the task description. (Show Details)Jan 6 2016, 6:23 PM

Change 423246 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[mediawiki/extensions/MultimediaViewer@master] Remove error report link

https://gerrit.wikimedia.org/r/423246

Change 423246 merged by jenkins-bot:
[mediawiki/extensions/MultimediaViewer@master] Remove error report link

https://gerrit.wikimedia.org/r/423246

Tgr added a comment.May 24 2018, 9:30 AM

One thing to learn from this is to make the error reporting mechanism wiki family specific. We are still getting error reports from third-party wikis running old MediaViewer versions, and probably will for a long time.

Tgr closed this task as Resolved.Feb 12 2019, 12:11 AM

Not sure why I left this open.