I've discovered this while fighting another issue: if you long-press a link to a video file to try and save it to your device (I occasionally do this while ripping videos from Twitter), you get the long-press context menu you want (with the "download linked file" item) for like half a second before the full screen video covers up your whole screen, and when you swipe it away the context menu is gone.
You literally have to race the video popup, and sometimes I just have to memorize the location on my phone's screen where the "download linked file" button will appear and have my finger ready over the spot because there's not enough time to scan over all the menu items.
FYI if you notice regressive behavior on YouTube in mobile Safari, eg unable to use the operating system’s picture-in-picture mode, this is due to Google injecting a script to close the video when focus leaves the page.
You can fix this bug by installing a Safari extension called Vinegar which will convert non-standard video containers to standard HTML5 video elements. As a bonus, this also prevents content injection by the malicious code that google sends to your browser to render content from third party advertisers on your device without your consent.
Yeah, it’s disappointing that content blockers and Safari extensions are not configurable per-app, in the same way as photos access or whatever else. This seems like an obvious feature, so hopefully the reason for its delay is complexity of implementation; IIRC app developers have basically full access to WebKit in a WebView, so enforcing the use of content blockers would be difficult. But Apple could make implementing content blockers for generic web views a requirement that they check for during review. I say “generic” because there are likely some use cases where the WebView isn’t being used as a general purpose web browser, like it would be in Apollo or Feedly. So it might be infeasible as a hard requirement.
On the other hand, Apple wants to incentivize developers to build apps, and they have a history of gatekeeping features from the browser to force certain use cases into the App Store. So hopefully they’re not omitting this setting to encourage app developers to create apps where they can run their “safe ads” without content blockers.
On Android, they solved this with "Custom Tabs", which is an API that opens a nicely integrated webview with extra buttons added by the app (like a tweet button) but internally is the default browser. Almost all apps use this now. I have this with enabled with Firefox
Yeah SponsorBlock is the only reason I still have Firefox installed on my Air. YouTube is horrible without it. I already pay for Premium, I refuse to put up with more ads.
> this also prevents content injection by the malicious code that google sends to your browser to render content from third party advertisers on your device without your consent
You’re kidding right?
Deliberately watching videos on a freely provided service supported by ads, makes the ad script “malicious and non-consensual”?
I meant it facetiously, but I’m definitely not kidding.
It’s my device, so I can choose what code executes on it. If I choose to block code from executing, that must mean I did not consent to its execution, because otherwise why would I need to block it?
I owe no debt to Google, especially since YouTube is often a non-consensual venue, in the sense that content I want to watch, which Google did not create, is only available on Google’s website.
I was not an active participant in the economic conditions that led to Google’s monopolization of the video hosting market. So if I am only watching a video on YouTube because it’s only hosted on YouTube, but I would have watched it if it were hosted elsewhere, then I am only passively responsible for the choice of watching it on YouTube.
I do not owe anything to Google in this case, because it implies I benefit from the existence of YouTube, but any benefit I derive is actually from the content, not the host of it.
The suggestion that I benefit from Google’s monopoly on video hosting presupposes the idea that free-to-watch video hosts cannot exist without serving advertisements. I don’t believe that, and I always choose alternative hosts over YouTube in the rare case where a video is hosted on both, or banned from YouTube.
I don’t use SponsorBlock, although I do manually scrub past promotional content.
I always assumed this was part of their deal with records companies to basically prevent people using YouTube as a free music streaming service (while keeping music videos there). Partly because before iOS added picture-in-picture they had a feature to enable videos to keep playing as audio only in the background but ONLY if you had YouTube Red/Premium.
Having said that, they now enabled Picture-in-Picture on iOS (though last check it's still in beta I joined the beta a while back) and one of Apple's requirements is you cannot but OS features (such as Picture in Picture) behind an app paywall. So they could only do this by making it available to everyone including free users. Not sure what got them over the line but its there now.
So makes me wonder if that will go away - or whether they still enforce that requirement on Android, or what.
if you long-press a link to a video file to try and save it to your device (I occasionally do this while ripping videos from Twitter), you get the long-press context menu you want (with the "download linked file" item) for like half a second before the full screen video covers up your whole screen, and when you swipe it away the context menu is gone.
Is it possible that this is related to the iOS link preview feature?
When you long-press a link, do you get the full destination page preview? That might explain why the phone renders the page, including the video taking over.
Long-press on another page link (like one here on HN), and you have a tiny option at the top-right for "Hide preview," select that. Then try another link that has a take-over video, and see if it no longer does that.
If you hate video takeovers more than you like link previews, this might solve your problem.
I don't recall ever using link previews very much. I suppose if I really need it I can toggle it on for that specific instance, but as it is it's not worth it for the video hijacking
Web devs have been saying they want to take over the native app experience for 20+ years, and after all this time we’re still stuck with shit like this.
Edit: I just opened weather.com on mobile and I rest my case.
iOS Safari can play videos non-fullscreen with the playsinline or webkit-playsinline attributes. The fun thing though is that this attribute must be enabled manually on each web view, so if some other app is embedding your page and they didn't enable it, your videos will play fullscreen despite the attribute being set.
In general browser vendors don't care about DoS bugs like this.
If a web page can do something that stops the browser responding or locks it up, the browser vendor won't fix it. They'll just say "well don't visit webpages that do that then".
I did not. I already wasted enough time and energy in the past reporting a security vulnerability in Safari's CSP to know that reporting it is not worth it.
I couldn't help notice you've exploited your observation in order to promote your blog. There seems to be an awful lot of Apple shaming for self-promotion and entitlement to do so without reciprocating the free attention by taking 5 minutes of your precious time to file a bug report. And I, for one, love how you don't even provide any version information, no iOS version details, no mobile Safari version details. Nothing. Maybe your bug reports are discarded because you fail to provide any salient details.
But I think you're absolutely right. A bug report will serve no purpose, because this is definitely not a bug, i.e. not a flaw in code that causes the software to crash or explode. It is instead leveraging a quirk of interface design in order to garner attention for an otherwise unremarkable blog.
Definitely looks like the kind of bug I'd find exploited on early Internet Explorer. Open a suspicious tab, get spammed with fullscreen ads! Now that's thinking differently.
The worst experience I’ve had on iOS, fairly recently, was clicking on a search result and being redirected to a dodgy website which displayed a “your phone has a virus!” pop up, started attempting to call a phone number repeatedly, and somehow corrupted the OS to where I saw a distorted version of the left-hand slide menu from the home screen, could not go to the home screen, close the app or reboot. I managed to reboot through a different method but it’s made me very wary of going to random websites on my phone.
The corruption of the interface was the most disturbing thing. It was showing the left-hand slide home screen menu offset, overlapping with other elements, without any ability to interact with it. It must be some sort of memory corruption vulnerability, I assume. Apple did an update a week or two later which addressed some sort of zero day… So clearly I was wondering exactly how hacked my phone might have been. I was able to reboot and it has seems OK, but who knows.
It prevented me from launching, switching or killing any apps or rebooting the phone. The phone was entirely unusable until I figured out how to reboot. That's more than visual. My impression is that is was memory only, but it was extremely suspicious. It’s quite possible that data was exfiltrated.
Simply locking up Springboard with a DoS doesn't necessarily mean your were breached on the device. It's more likely that nothing came of it, exfiltrating data would involve breaching a lot of sandboxing and we'd be seeing a lot more chatter about that honestly.
Sure, there’s been no evidence of anything wrong since then, either with my phone or related accounts. Apple did fix a couple 0 days with more serious implications shortly after this, but it’s not as if I or a random search result website would be worth someone using a 0 day.
I have a project where this is a legitimate use case. Indeed, Safari was the only browser where it was possible to implement without trickeries… eventually the team managed to get a version for Firefox snd chromiums as well (on desktop too).
A bug is an error in source code that causes a program to produce unexpected results or crash altogether, i.e. something that doesn't work, something broken; the user initiates an action, the action fails or program crashes. That isn't what this is. This is the user intentionally opening multiple overlapping fullscreen videos. You can make a computer saturate its processor indefinitely with a while-loop, but doesn't make it a bug.
The user isn't the one intentionally opening these overlapping videos. The site they're visiting is making that request, and the browser is honoring it.
This is a bug. These are unexpected results! And as the article notes, "sometimes this behavior makes Safari crash."
So a website can make your browser crash by getting it to do something nonsensical (opening 30 overlapping full screen videos), without your forewarning that this could happen.
You can quibble and say it's a "misfeature" or similar, but I'm not sure that means much.
> The user isn't the one intentionally opening these overlapping videos.
Yes, he absolutely is, and the proof is
> So here’s a tiny web page I created to play with it.
What OP is reporting is more accurately described as a possible memory overflow exploit. The software appears to be operating as designed, but a malicious attacker might be able to exploit the behavior to do bad things, though this is not exactly necessarily true, and we won't know until we see it happen.
This is weird. Okay, so it may not be a software bug at all, but I'm gonna move these goalposts and insist this is a product design bug, or something.
If this is intentional behavior, I don't understand the point. A full-screen video should be the only one playing IMO. Playing multiple (windowed) videos is one thing, but having 30 of them overlap full screen is quite another. And with no affordances to mass-terminate them, the result is unwanted behavior.
So: not a bug in the "off-by-one" or "use-after-free" sense, but damn if it ain't a close cousin.
> Playing multiple (windowed) videos is one thing, but having 30 of them overlap full screen is quite another.
Behavior can be duplicated on any modern computer, i.e. you can have as many overlapping fullscreen windows as memory will tolerate, probably thousands and much more than that. Why would anyone want to do that? To cry "bug," I imagine.
It may not be intentional design, but my point is that this is not a bug, by the definition of what a bug is. There is no actual error here. The code is operating as expected. There may be issues with the interface design, but there also very well may not be.
I highly doubt this. When Apple rolled out multiple video support, they did not expect that a random website could—having gained permission to spawn one video player—reuse that blessing 29 more times.
The browser will prevent auto-playing videos from spawning absent a user interaction. This is a feature that prevents pop-up hell. With this change, they failed to update the "make sure user is cool with this" code.
It's a regression, and will be fixed in an update or I eat my hat.
Again, I know this isn't some "error found on line 384 of vid.cpp" or whatever, but it's definitely not the way Apple wants this to work.
My desktop browsers won't do this, nor any other browser I've used in the past 10 years.
mobile Safari is a little different than desktop browsers. It uses the same engine as desktop Safari, but I've always suspected the video player is not built-in to the browser, but instead a separate and discrete application. I suspect this because every other application appears to have an identical video player. Maybe they're all sharing code, but more likely the video player is system-available to any application. But running multiple instances of that video player on iOS is academic. Why you're not able to duplicate this in any of your desktop browsers in the last decade is anyone's guess.
>Why you're not able to duplicate this in any of your desktop browsers in the last decade is anyone's guess.
Because it's a bug not an intentional design choice. If you can provide a legitimate use case for being able to open 30 overlapping fullscreen videos from a single user click on a web site then you might have a some sort of argument.
This doesn't work on desktop Safari thankfully, if it did you could make some argument they are sharing code and trying to make iOS more like a desktop OS with multitasking, but no again there is no reason to do this on any OS other than to crash users browsers.
First of all, there is no use case for this very specific implementation of multitasking, fullscreen and overlapping windows. Second of all, the OP created and invented this. Though OP claims this behavior was innocently stumbled upon, it is clear, upon discovery of the behavior, the OP intentionally produced this behavior with their own webpage.
There is no error here. The code works precisely as intended, thus, this is not a bug, because bugs are errors in code that breaks the program's execution. That is not happening! The program still works and keeps on working until OP makes mobile Safari crash by intentionally eating up all the memory.
A software bug is an error, flaw or fault in the design, development, or operation of computer software that causes it to produce an incorrect or unexpected result, or to behave in unintended ways.[1]
Please continue to review the first 6 words of the definition until it sinks in that a bug is an error in the code, and a bug is not a quirk of interface design that you don't care for. If there is no flaw in the code, then there is no bug.
What OP and you and everyone else that apparently doesn't understand what a bug is are complaining about is this particular facet of mobile Safari's interface design. So if there is a problem here, it is not a flaw in the program code. It is a weird behavior that occurs when and only when the user decides to make their browser do weird things by creating a webpage to intentionally cause it. It sounds pretty darn unlikely to be repeated by anyone, and afaict, no one seems to have duplicated the behavior and reported back. But this is beside the point because the code is executing precisely as expected, and the program or system is not crashing because of this behavior, if it is crashing at all.
Again, this is not a bug. It is an entirely different animal.
>Please continue to review the first 6 words of the definition until it sinks in that a bug is an error in the code, and a bug is not a quirk of interface design that you don't care for. If there is no flaw in the code, then there is no bug.
A software bug is an error, flaw or fault in the design, development, or operation of computer software that causes it to produce an incorrect or unexpected result, or to behave in unintended ways.
This behavior is a fault in the design of the browser code handling full screen video playback based on a user click, it produces an incorrect and unexpected result that can lead to breaking the programs execution (Safari crash).
You are doing some serious mental gymnastics over a single word "bug" that everyone else seems fine with. You still have not provided a legitimate use case for this behavior that would explain how this is expected and correct behavior as seen by the designers.
> I've always suspected the video player is not built-in to the browser, but instead a separate and discrete application. I suspect this because every other application appears to have an identical video player. Maybe they're all sharing code, but more likely the video player is system-available to any application.
> It may not be intentional design, but my point is that this is not a bug, by the definition of what a bug is. There is no actual error here. The code is operating as expected. There may be issues with the interface design, but there also very well may not be.
Is this a useful distinction? The user expects something, the designer expects something different. Just the other day I read about Jeep's Monostable Shifter (https://www.youtube.com/watch?v=jD1-aQSO5Hg) and how it was attributed to people getting hurt or dying. It's operating exactly as designed and intended but was still recalled.
No they aren't there is a button that the user clicks that runs code to play multiple overlapping videos. This serves no conceivable purpose and can cause the browser to crash, it is a bug.
The reason it works is the code is run from a user action, the problem is after the first video play the browser should no longer consider the subsequent plays a user action, or it should only play the last video and cleanup the now overlapped previous video.
You're talking about design choices, not errors or software bugs. You have a design preference that more than one fullscreen video should not be permitted. But this is entirely an arbitrary preference. There is absolutely nothing inherently wrong (ethically or design-wise) with multiple overlapping fullscreen videos, though the OP is describing a very particular case that is strange, which is having multiple instances of the same video playing fullscreen. It's still not a bug. This is interface design.
> You have a design preference that more than one fullscreen video should not be permitted.
I think this is where you and I are talking past each other. I'm not saying that multiple videos shouldn't be allowed. That's not the problem here.
The problem is that Safari has a mechanism to ensure that the user wants a video to play. That mechanism looks for some UI action on the user's part before it will allow a site to launch the video player. With this new multiple-video feature, that mechanism is now broken. It'll say, "Hey you want to play this video? Yeah, ok, I will allow it, and any other video the site wants to spam you with now."
That italicized part is the bug. It shouldn't assume the UI action applies to an arbitrary number of separate videos.
The video player is fine. That's the design choice. The Safari code not accounting for that is the bug.
You're still talking about interface design and not an error in the actual code. You're talking about how the user is interacting with the software, and/or how a website developer writes up his crappy site. The software itself isn't broken. But the interaction between user and client and server is getting under your skin and you're insisting it is a bug... when it simply is not a bug.
"Every time a try to click this link, my browser crashes!" <--- that sounds like a bug.
"I'm able to create a webpage that exploits a user interaction to create weird behavior" <---- not a bug! if a problem exists it is within the realm of User Interface Design and not software design or anything within the code itself. The design choices may cause a need to rework the code, but that doesn't make a bug magically appear in the code.
He found a bug and made a proof of concept webpage to demonstrate it. So when he talks about it he is both the user and the author of the web page. In general You wouldn't expect them to be the same person.
And I'd agree, except that this behavior is an advertised feature of the of the system, iow, if you open multiple fullscreen videos, you should expect to see what is seen as opposed to Safari crashing or the system crashing.
Hmm, is opening a fullscreen video considered opening a new application, or is it considered a single application (the browser) displaying different content? I thought it was the second case, so multitasking I don't think applies. Same for desktop chrome, when it shows a fullscreen video, that's not a new application, just the browser displaying content in a new way.
For picture in picture mode, I don't think multiple fullscreen videos should be a valid configuration of picture in picture.
I recently experienced almost the same bug, I opened YouTube in a normal tab and was able to play another video in a private tab and both videos played simultaneously.
That feels like a bug worth independently filing. I'm not sure what I expected the behavior of a private tab to be, when "backgrounded" in favor of a normal one, but it's not that.
You’ve got a weird config that seems to make it not happen to you then. On a fresh device, stock options, running beta 1 I still see this issue. It’s not nearly as bad as it is in his video demo but it still exists.
You literally have to race the video popup, and sometimes I just have to memorize the location on my phone's screen where the "download linked file" button will appear and have my finger ready over the spot because there's not enough time to scan over all the menu items.