@Etonkovidova From the image displayed it means that the VUE application is failing to load (hence no dropdown and open in a new tab).

This is quite luckily due to the upgrade of vue to VUE 3.

What are the company policies with older browsers? What is the expected support? (it may be that this is a small bug, but it could also turn out to mean that we need to revert back the VUE migration if this is a must have)

As per Elena's comment in T299253, according to https://www.mediawiki.org/wiki/Compatibility#Browser_support_matrix, Safari 9+ versions should be supported. cc @egardner

As per initial investigation I can confirm that the issue is related to VUE 3. The imported library requires ES6 and this is not allowed in the browser provided.

I have reached out to the design team to ask if this was the plan all along (for the vue 3 compatibility mode to drop support) or if it was a mistake. If it was a mistake we will rectify it, if it was the plan all along, we will have to revert back to Vue 2!

Hi all – the short answer here is that this is expected behavior. The MediaWiki-provided copy of Vue.js has been upgraded to version 3, which drops support for non-ES6-supporting browsers (this includes Internet Explorer 11 as well as some old versions of Safari, including Safari 9). Users of these old browsers can still access the non-JS version of the page, but things like filter dropdowns and the Quickview won't be part of the experience in that case.

Early last year there was a discussion within the Product Department (facilitated by Jon Katz) around deprecating support for browsers that cannot run modern JavaScript (aka ES6, which has been the standard for more than 5 years at this point). The conclusion was that newer features would start dropping JS support for non-ES6-compatible browsers because continuing to support them in this way is becoming a significant drag on development efforts, and the number of users still running these legacy versions is miniscule. In cases where we still want to provide a feature to users of these old browsers, the best way to do this is by providing a usable "fallback" interface (non-JS-based). This is what MediaSearch is doing now.

The decision to use Vue 3 (and thus drop JS support for IE11 and other legacy browsers like Safari 9) was re-affirmed at the Designer/Developer summits facilitated by the Design Systems Team last summer (see T286947 and T286947 for example). For new JS-based features and anything that uses Vue, we are working with the assumption that support for users of legacy browsers – if it is a requirement for a given product at all – should be provided via a non-JS-based fallback UI.

At some point in the near future we likely will downgrade non-ES6 browsers to "basic" support for all JS features (see T178356), but some critical features like Visual Editor will likely continue to support legacy browsers for some time.

One more comment: everything above holds true for IE 11 and Safari 9 (these are legacy browsers that do not support ES6, so they won't get the interactive version of Vue-based features going forward).

For Safari 10–13, I would not expect there to be a compatibility problem. So if users of these versions of Safari are not getting the "full" MediaSearch experience, then that is a bug worth investigating. It may be that some of the code in ResourceLoader which determines whether or not the full ES6 environment is available (added as part of T272104) is stricter than we need it to be.

This would be worth investigating; I'll open a follow-up task on the DST board to look at Safari 10-13 support in RL modules that specify es6: true.

Update from @egardner: I've proposed making a change to how MediaWiki checks for ES6 support (https://gerrit.wikimedia.org/r/c/mediawiki/core/+/759532 – still in progress, via T300666) with the goal of restoring functionality for Safari 10+ users (safari 9 will not be supported, too out of date). That should fix things for once we have an agreed-upon solution.

Blocked on T300666

We are working on making some small changes to ResourceLoader that should restore functionality to users of desktop & mobile Safari from version 11+. Versions 9 and 10 will still be excluded, but if there is significant Safari 10 traffic we can investigate further changes. Do we have traffic stats for Special:MediaSearch or SuggestedTags?

In T300094#7676495, @egardner wrote:

We are working on making some small changes to ResourceLoader that should restore functionality to users of desktop & mobile Safari from version 11+. Versions 9 and 10 will still be excluded, but if there is significant Safari 10 traffic we can investigate further changes. Do we have traffic stats for Special:MediaSearch or SuggestedTags?

MediaSearch traffic stats are here, but they're not broken down by browser: https://superset.wikimedia.org/superset/dashboard/236/ @cchen might be able to help if it's needed.

CAT usage stats are here, they're also not broken down by browser:
https://analytics.wikimedia.org/published/notebooks/computer-aided-tagging/CAT-usage-report.html

MediaSearch traffic stats are here, but they're not broken down by browser: https://superset.wikimedia.org/superset/dashboard/236/ @cchen might be able to help if it's needed.

CAT usage stats are here, they're also not broken down by browser:
https://analytics.wikimedia.org/published/notebooks/computer-aided-tagging/CAT-usage-report.html

For some reason I can't access these – when I log in to the dashboards I just see a message that says "Presto Error". If anyone is able to get a breakdown by browser and version, that would be useful.

Regarding the bug itself, In the simulator running iOS 12.4 (the oldest version I can run locally, which includes Mobile Safari of the same version number), I am able to confirm the following:

1. MediaSearch only runs in the non-JS version in Safari 12 (no filters or Quickview)
2. This patch (https://gerrit.wikimedia.org/r/c/mediawiki/extensions/MediaSearch/+/759624) restores full functionality in Safari 12 (and presumably also in v11).

This should be able to go out on next week's train. After that, would be good if QTE could verify.

In T300094#7676655, @CBogen wrote:

In T300094#7676495, @egardner wrote:

We are working on making some small changes to ResourceLoader that should restore functionality to users of desktop & mobile Safari from version 11+. Versions 9 and 10 will still be excluded, but if there is significant Safari 10 traffic we can investigate further changes. Do we have traffic stats for Special:MediaSearch or SuggestedTags?

MediaSearch traffic stats are here, but they're not broken down by browser: https://superset.wikimedia.org/superset/dashboard/236/ @cchen might be able to help if it's needed.

CAT usage stats are here, they're also not broken down by browser:
https://analytics.wikimedia.org/published/notebooks/computer-aided-tagging/CAT-usage-report.html

yes, i can pull the data for browser and version if needed.

In T300094#7677078, @egardner wrote:

Regarding the bug itself, In the simulator running iOS 12.4 (the oldest version I can run locally, which includes Mobile Safari of the same version number), I am able to confirm the following:

1. MediaSearch only runs in the non-JS version in Safari 12 (no filters or Quickview)
2. This patch (https://gerrit.wikimedia.org/r/c/mediawiki/extensions/MediaSearch/+/759624) restores full functionality in Safari 12 (and presumably also in v11).

This should be able to go out on next week's train. After that, would be good if QTE could verify.

Yes, checked on commons wmf.21

• Special:MediaSearch on Safari 15-11 does display the drop-down filters.
• QuickView works as expected
• Safari 9-10 still have the issue

However, there is another issue - if no selection is made on those filters, they won't get dismissed when another filter is clicked - filed as a separate issue - T301439: [M] [wmf.21] Safari 15 - Special:MediaSearch several drop-down filters displayed at the same time.