1. Go to any Apple trailers page like: http://trailers.apple.com/trailers/paramount/dinnerforschmucks/ 2. Click on "Watch now" 3. Gray area pops up, and no movie Do the same thing in Firefox, with Totem's QuickTime-compatible NarrowSpace plugin, and it will work as expected. The builtin video support should only kick in when: - Playing in "full-screen" (when mode is NP_FULL) or - When a plug-in handling the mime-type is already available or (obviously) - When a video or audio tag is used
It seems r56650 introduced this "bug". It enables proxying to a MediaElement. It actually works but the User-Agent is not set "apple-friendly" by the FrameLoader in this case and that's why you see nothing. Apple webserver sents a 302 response because of that ... user-agent filter they have.
Created attachment 55701 [details] proposed patch
I don't agree with that patch one bit. The patch still doesn't allow for the controls to be used in the display, because the web page expects a plugin compatible with QuickTime, not builtin HTML5 video support. If I wanted that sort of patches to get into WebKit, I would have mentioned what the work-around was. I want WebKitGTK to stop taking over <embed> and <object> mime-types that are handled by plugins.
See http://trailers.apple.com/trailers/global/scripts/lib/ac_media.js // added a check for Google Chrome; until they fix their .mov wrapper bug we can't serve the <video> element 135 if (shouldBuildMediaSpecVideo && Media._isHTML5VideoAvailable() && 136 !Media.Detection.Firefox() && !Media.Detection.Mobile() && 137 !Media.Detection.Chrome()) { 138 // Create <video> player 139 return build(Media.Spec.Video); 140 } 141 142 if (shouldBuildMediaSpecQuickTime && 143 Media._isQuickTimeAvailable(Media.MIN_QUICKTIME_VERSION) || 144 Media.Detection.Mobile()) { 145 // Create QuickTime player 146 return build(Media.Spec.QuickTime); 147 } So the logic is to check if the browser supports HTML5 video and video/mp4. If so a video element is created instead of an <object>... So, not sure what I can actually do. I won't blacklist video/mp4 from our player. Have you tried the patch?
(In reply to comment #4) > See http://trailers.apple.com/trailers/global/scripts/lib/ac_media.js > > // added a check for Google Chrome; until they fix their .mov wrapper bug we can't serve the <video> element <snip> > So the logic is to check if the browser supports HTML5 video and video/mp4. If so a video element is created instead of an <object>... So, not sure what I can actually do. I won't blacklist video/mp4 from our player. Have you tried the patch? Right, it's my mistake for thinking that WebKitGTK was taking over from the <embed> property. Are you sure that's what it's doing? I still don't understand why a User-agent matching *QuickTime* (as opposed to one matching the Safari version) would make a difference to the website, if you were using a <video> tag.
(In reply to comment #5) > Right, it's my mistake for thinking that WebKitGTK was taking over from the <embed> property. Are you sure that's what it's doing? > Well yeah that's what I conclude. I could see in gdb that the video element is created from Javascript. I also tested with Chromium, no <video> element is created, likely because of the checks in that js script. I could be wrong but I didn't see any place in WebKit code where we replace an <object> with a <video> element. > I still don't understand why a User-agent matching *QuickTime* (as opposed to one matching the Safari version) would make a difference to the website, if you were using a <video> tag. That confused me too. I think we never correctly sent the "Quicktime" UA. I don't see how it could work in the current call order, there was no change in the frameloader changing the behavior. You currently only see a gray rectangle because our player get a 302 error from apple webserver, because we don't send the correct user-agent (I checked with wireshark).
Right. So the last problem is whether you want to hard-code a user-agent for a website into the webkit code.
Comment on attachment 55701 [details] proposed patch Can I suggest renaming this bug report before committing, and making sure the changed name is reflected in the ChangeLog, since your investigation concluded it has nothing to do with WebKitGTK+ taking over from plugins? =)
Thanks for the review Gustavo. Landed the patch in http://trac.webkit.org/changeset/60219