Ran just now iOS 12.5.8 via iPhone 5s, and the non-free videos still work at my end. Well, the resolution is "SD 360p".

Besides me, does someone else here possess an Apple device running iOS 12?

first, do you still have a device running iOS 12?

I haven't yet encountered the same issue recently on iPadOS 26.7 via iPad 9th-gen.

The prioritization level should be raised to either medium or, preferably, high. Indeed, I think this is what most users have wanted all along.

How about already "Resolved" then?

As I was told, a local interface admin should be skilled enough to modify image settings for a local site: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#c-Mr._Starfleet_Command-20260827172500-George_Ho-20260827171700

This could probably also be done as a user script.

In T429706#12197876, @Mr._Starfleet_Command wrote:

Did you read my comment above, where I said, "the earliest we might fulfill this task is some time next year, so not an immediate worry"?

Wait... Ending support for Firefox ESR 52 (0.005% viewership) and Chrome 49 (0.031% viewership) would mean ending support for especially Windows XP and Vista, huh? (Source: Wikipedia: Chrome, Firefox)

@Ahecht Firefox 115 has given 0.143% viewership, FWIW.

The only practical impact is that Safari 13 won't receive the Modern layer anymore (JS enhancements). MediaWiki sites will still be accessible and usable for the most part. Is there a particular reason you think we need to continue to fully support Safari 13 for much longer?

In T380576#12197096, @Mr._Starfleet_Command wrote:

[...] we must at the very least raise the Basic requirement to Chrome 67. And, if we also set a support target, that should be 7 or 8 years, which should also apply to Firefox (barely adds to the page-view share, not to mention they already share a Modern target of 3 years)

@Mr._Starfleet_Command Just in case, list of iMac and macBook models for you to look at.

In T429706#12197040, @Mr._Starfleet_Command wrote:

In T429706#12197006, @gh87 wrote:

...I can't help wondering how this active task will affect macOS Safari 13 and iOS Safari 15.

According to CanIUse.com, ES2020 is fully supported in Safari 14.1+, so we'll probably drop Safari 12 and 13 when we next raise the JS requirement.

Now that the T434032 is closed as a "duplicate" of this active task, I can't help wondering how this active task will affect macOS Safari 13 and iOS Safari 15.

Statistics
Safari 12-15 makes up 0.370% of all WMF page views.

Let's not forget login issues illustrated at T422219

Should also note T422219: Unable to login from Grade C browsers (WebAuthn imposes a JS requirement)

@Mr._Starfleet_Command Also, T355596 was declined because the devs were unwilling to fix the login issue on iOS 12 (T355596#9519994), which still has had declining and very low userbase anymore.

Thanks for changes to, i.e. copyediting, the whole description. As I shall further note, ending support for certain Safari versions would also mean ending support for certain iMac and macBook models, though let's acknowledge especially iPhone and iPad users as also important userbase.

FWIW, the error message was, "No compatible source was found for this media."

As I see, the 144p resolution is dropped. While Commons videos still work on iPhone 5s, local non-free files may no longer work due to change from VP9 to 360p MPEG-4 Visual.

In T380576#12186068, @Mr._Starfleet_Command wrote:

Personally, I'd argue for an 8-, 9-, or 10-year support target. That would keep the page views leaving Basic below 0.1% (0.916%, 0.433%, or 0% respectively).

AFAIK there's no such hesitance on the part of the WMF to continue supporting older browsers -- what comments are you basing this on?

I appreciate your concerns about supposed redundancy. Nonetheless, this is a response to the task you were referring to and the Firefox one. Also, smaller tasks are easier to track and develop than bigger ones, IMO.

Shall this task be stalled then? I just now created T434032: Drop Modern (Grade A) support for Safari 12.

We'll agree to disagree, huh? Shall we stall the other task and then go for this task instead?

Shall we not treat iOS Safari and macOS Safari as the same please?

As I see, the task is still not yet "stalled" at this time. I can't believe you all that you wanna go through with this, don't ya?

As I see, Media Viewer no longer upscales smaller images. Nonetheless, a filepage can still upscale its smaller image.

Almost a year has passed, so... how has been the analysis going so far?

iOS 8 is no longer supported. Please create newer task if similar issues still persist in newer iOS/iPadOS versions. Thank you.

I see. Adding two tasks as sub-tasks. Will stall this parent task for now

Wait! Wasn't this resolved per T106267#1634630? Indeed, totally forgot that it's considered unrelated

Oops! I barely knew how to merge the other into this one

Android 4 is no longer supported: https://www.mediawiki.org/wiki/Compatibility#Browser_support_matrix

Now moot. iOS 9 is no longer supported: https://www.mediawiki.org/wiki/Compatibility#Browser_support_matrix

In greater context....

Meanwhile, shall I then change the status of this task from "declined" to "stalled"?

Oh... Forgot about "File:" namespace. Something for especially Commons users to list into their own reading lists, like images.

• "Wikipedia:" namespace: Good for someone to reread policies, guidelines, and essays. Also, saving a Village pump page in case a user wants to return someday. I can explain others, like WikiProjects, if you want more.
• "Draft:" namespace: Just in case a user likes to take a "Draft:" page off one's own Watchlist
• "Template:" namespace: Like "Draft:" above

The Media Viewer already enlarges or stretches a non-free image, like this one shown in screenshot: https://en.wikipedia.org/wiki/I_Will_Always_Love_You_(Whitney_Houston_recording)#/media/File:I_Will_Always_Love_You_by_Whitney_Houston_US_CD_single.jpg

In T421524#12026938, @Mr._Starfleet_Command wrote:

In T421524#12026665, @gh87 wrote:

I'm also worried that copyright infringement might be possible, especially by upscaling non-free images to whatever they shouldn't be.

To be clear, the "upscaling" is really just stretching the images to be larger and thus more blurry. No extra quality is added, so I don't see how it could cause copyright problems.

Reading T421524#12026345, I don't know how else to dispute this as a reason to decline this. I'm also worried that copyright infringement might be possible, especially by upscaling non-free images to whatever they shouldn't be.

Works now on the Patch Demo website via Firefox ESR 115

Desktop view on Safari via iPadOS 26.5:

In T421524#11995123, @Jdlrobson-WMF wrote:

Do any of these apply?

As I noticed, upright may no longer work properly?

• When I entered between 0.5 and 0.99, the size is the same.
• When I entered between 0.2 and 0.49, the size is perhaps the same smaller size
• When I entered 0.1, the size is perhaps smaller than above but not variable

@Jdlrobson-WMF Just trying to find JS-related project tags. Dunno any other. Never intended to reinsert the MobileFrontend tag or add a subproject tag, ya know.

My skin for the mobile web is Vector 2022, and the mobile web has been crashing under that skin also. What's the URL code for that one?

increase their image quality accordingly