@JScherer-WMF

Sorry @egardner just getting to this today.

For feature parity with the MobileFrontend viewer, we need a single unified error state (we can adopt the legacy desktop viewer's more granular approach later if needed). User-facing error messages should use the new Codex Toast component (available in Codex 2.4.0, now in MW core), which provides toast notifications with built-in accessibility (role="alert"), swipe-to-dismiss on mobile, and auto-dismiss support.

This seems like a fine approach for our initial experiment. We can always improve later.

We may be able to re-use an existing error message template

Great idea. I would prefer to re-use existing error message templates to avoid re-writing and re-translating new strings.

Change #1290009 had a related patch set uploaded (by LWatson; author: LWatson):

[mediawiki/extensions/MultimediaViewer@master] Image Browsing: error handling for beta viewer

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

Given our goal is feature parity with the Mobile Frontend viewer, should we match their existing error display method, or is it okay to introduce the Codex Toast component?
Can you confirm where to display the error message? @JScherer-WMF

Legacy version:
The Mobile Frontend viewer displays the error message.

In T422268#11955084, @lwatson wrote:

Given our goal is feature parity with the Mobile Frontend viewer, should we match their existing error display method, or is it okay to introduce the Codex Toast component?
Can you confirm where to display the error message? @JScherer-WMF

Legacy version:
The Mobile Frontend viewer displays the error message.

Great catch @lwatson. I'll mock something up for this right now.

Ok, so the toast component makes the most sense, and we can use the exact same copy and CTA.
I mocked this up in Figma and marked it ready for dev.

Assuming this task is about the MediaViewer code project, hence adding that project tag so other people who don't know or don't care about team tags can also find this task when searching via projects or looking at workboards. Please set appropriate project tags when possible. Thanks.

Change #1302283 had a related patch set uploaded (by Eric Gardner; author: Eric Gardner):

[mediawiki/extensions/MultimediaViewer@master] ImageInfo: Add invalidate() to evict a single cached entry

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

Change #1302283 merged by jenkins-bot:

[mediawiki/extensions/MultimediaViewer@master] ImageInfo: Add invalidate() to evict a single cached entry

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

@JScherer-WMF Regarding the localized messages: the legacy mobile messages are stored in MobileFrontend (not MultimediaViewer), so I created new messages in MultimediaViewer to maintain parity. The downside is that this increases translators' workload and requires waiting for new translations to come in. An alternative is to reuse the existing translations from the legacy desktop messages in MultimediaViewer. Do you have a strong preference either way?

I. MobileFrontend - https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/master/i18n/en.json

II. MultimediaViewer - https://github.com/wikimedia/mediawiki-extensions-MultimediaViewer/blob/master/i18n/en.json

If you can use the old strings, that would be ideal.

Change #1290009 merged by jenkins-bot:

[mediawiki/extensions/MultimediaViewer@master] Image Browsing: error handling for BetaViewer

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

Testing Notes:

• check the test cases as per https://phabricator.wikimedia.org/T422268#12024849
• check if these elements fail to load
  • img
  • title
  • author
  • img metadata

According to MVP proposal in task description:

For feature parity with the MobileFrontend viewer, we need a single unified error state (we can adopt the legacy desktop viewer's more granular approach later if needed).

enwiki wmf.7	Figma design	enwiki wmf.8 (or enwiki beta)
		enwiki beta

Notes

• I was not able to trigger other error messages, i.e.

"multimediaviewer-metadata-error": "Could not load image details (error: $1)",
"multimediaviewer-file-not-found-error": "Sorry, the file $1 cannot be displayed since it is not present on the current page.",
"multimediaviewer-thumbnail-error": "Sorry, the file cannot be displayed",
"multimediaviewer-thumbnail-error-description": "There seems to be a technical issue. You can $1 if it persists. Error: $2",
"multimediaviewer-thumbnail-error-retry": "retry",

@lwatson - please review the test results and let me know if more testing is needed.

Hey @Etonkovidova! My bad for not posting an update about the error messages. We ended up using these existing desktop error messages: multimediaviewer-file-not-found-error and multimediaviewer-thumbnail-error. We added a new message, "Refresh" (multimediaviewer-thumbnail-error-refresh-button), to MultimediaViewer.

Testing different error states:
I. Error loading the image

• Test via distorting the image src in the dev tools Element panel.
• Expected behavior: Displays a toast notification with an error message and "Refresh" button. Uses the Codex Toast to display the message. The viewer remains open, and the user can dismiss the error message. Swipe to dismiss the toast message on mobile or use the close button on a tablet/desktop device.

II. API failure

• Test via blocking the URL in the dev tools Network panel.
• Expected behavior: same as case I above

III. Image not found error

• Test via navigating to a hash URL with a file title that is not present on the current page (e.g. #/media/File:DoesNotExist.jpg). Example: https://en.wikipedia.org/wiki/Cardinalidae#/media/File:DoesNotExist.jpg
• Expected behavior: The viewer closes and a mw.notify() popup appears with the message "Sorry, the file [filename] cannot be displayed since it is not present on the current page" and a link to "Go to corresponding file page". The notification auto-dismisses after a few seconds.
• Please verify if pressing the browser back button after the notification returns to the broken hash or skips it cleanly.

Thank you, @lwatson - will do more testing today and post the test result summary.