This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
(Feel free to close this bug quickly if you understand that I am ’calling the wrong number’...) Safari has this unique problem where, when a media file is served via PHP, the plug-in that Safari hands the file over to (namely, to QuickTime ...) doesn’t play the file. (Yes, I talk about <video> and <audio> - and it doesn't matter whether the Safari runs on Windows, OSX or iOS - for iOS one can sometimes use Opera Mini(!) as a workaround.) In the particular LMS we use, the result is that the user gets kicked out of the LMS - so cookies are involved, meanign that Safari is unusable unless the author works around the LMS’s built in method for serving media files. I’ve reported the bug to Webkit, but was told it was an Apple specific bug. The issue is described many places: http://stackoverflow.com/questions/3089784/cant-serve-html5-video-through-php-on-safari-mac-5-0 And some believe they know the cause to be related to cookies - namely, that QuickTime doesn't pick up the cookie: http://stackoverflow.com/questions/3114406/single-php-exit-statement-prevents-html5-video-in-safari/3125869#3125869 But I also thougth the issue could be related to 'byte ranges: http://mobiforge.com/developing/story/content-delivery-mobile-devices http://www.somacon.com/p571.php For all I know, it could be Safari that does it the right way. Would be nice to get that clear.
So yeah, the problem is that QuickTime does not share HTTP state with Safari. Whether that's a bug or a feature seems unclear. I'd go with bug given that the idea of <video> is to not rely on plug-ins.
(In reply to comment #1) > So yeah, the problem is that QuickTime does not share HTTP state with > Safari. Whether that's a bug or a feature seems unclear. I'd go with bug > given that the idea of <video> is to not rely on plug-ins. What you say about ‘not rely on plug-ins’ was exactly my thinking. In fact, I got quite surprised when I found out that, in Safari, then <video> and <audio> hand their media over to QuickTime. I’ve asked some Apple guy about it, so I have some hope ... As is, this bug promotes use of Flash, IMO, since the trouble apparently isn’t found in Flash. But as for the Fetch spec, then, perhaps it should demand that plug-ins *do* share HTTP state? Because, plug-in or not should not matter to authors or end users, me thinks.)
I think that requirement would be redundant for <video> and <audio> at least. Plug-in usage there should be transparent as the fetches are required to share state. What plug-ins in <embed>, <object>, or a top-level browsing context do is really up to the plug-ins though I think.
Perhaps the Fetch spec could say that <video>/<audio> defines the pattern that plug-ins are expected to follow, regardless where plug-ins are used (<video> or <object>). At least for formats which the browser considers 'native, the most *realistic* thing to expect seems to be *same* behavior, regardless of <object> vs <video>. Also, if Fetch spec were to give special rules for special elements, then that would not be elegant, I think. I think there are two aspects fo 'native': native to the browser and native to the HTML language. And that the two are interlinked. In HTML4, there were no native <video> element, and thus browsers could also not offer any native user interface to <video>.
Browsers that use a different network stack for certain elements have a bug. Using a different network stack for plugins is questionable, but plugins are not part of the web platform and we cannot really control what they do.