*Steps to repro using Chrome ToT / Chrome 8.X dev: 1. Visit http://10tv.nana10.co.il/ (for example). 2. If you see a Hebrew message over the black video box, answer it by clicking on בטל (this button http://f.nanafiles.co.il/partner48/Common/Images//VideoPlayer/UI/CancelSaveProfile.gif ) 3. Wait for the video to load... it won't *I'm assuming r70748 is the cause because this issue appeared in Chrome between the following builds: http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog.html?url=/trunk/src&range=64245:64262&mode=html where there are 2 WebKit rolls: WebKit Roll 70722:70775. WebKit Roll 70775:70783 with the following WebKit changelog http://trac.webkit.org/log/?rev=70783&stop_rev=70722&verbose=on r70748 removed WebKit's map of classid values to MIME types. It also changed the behavior of object elements to render fallback content when a non-empty classid attribute is specified, which is the behavior HTML5 specifies when a UA encounters a classid it doesn't understand. http://trac.webkit.org/changeset/70748 https://bugs.webkit.org/show_bug.cgi?id=45679 *All tests took place under windows XP: Firefox (Minefield 4.0b8pre): OK Safary with ToT WebKit: OK Chrome ToT: FAIL Chrome ToT with Safari user agent: FAIL Chrome ToT with Firefox user agent string: OK As you can see Chrome+Firefox_user_agent works OK- Evangelism? but how come Chrome behaves differently than Safari in ToT? (assuming http://trac.webkit.org/changeset/70748/ is the cause?) inChromium bug: http://code.google.com/p/chromium/issues/detail?id=61418
We need a reduction. That page is too complicated. My first guess is that it requires another plugin that is not flash, or besides flash.
The Windows nightly builds are still on r70599, so that's why you can't reproduce this in the latest nightly. This page also requires the Windows Media Player Firefox plug-in installed in order to reproduce the bug (http://port25.technet.com/pages/windows-media-player-firefox-plugin-download.aspx). Here is the relevant markup served to Safari: <object classid="clsid:6BF52A52-394A-11D3-B153-00C04F79FAA6" type="application/x-ms-wmp" ...> Prior to r70559, we obeyed the type attribute and ignored the classid attribute, and we'd load the WMP plug-in. r70559 implemented HTML5's specified behavior for when a non-empty classid is encountered, which is to fall back when we don't recognize the classid (and after r70559, we don't recognize any classids). No plug-in loads in this case, which is correct behavior according to the spec. This page works in Firefox because Firefox is served an object tag with the classid attribute omitted, so a plug-in is loaded based on the contents of the type attribute. This is what the page should be serving to Safari and Chrome as well, as it would work reliably before or after r70559. This is best resolved by evangelizing the site to serve WebKit UA's the Firefox-style markup that omits IE-specific classids. I don't think we want to go back down the road of mapping classids to MIME types.
(In reply to comment #2) > The Windows nightly builds are still on r70599, so that's why you can't reproduce this in the latest nightly. This page also requires the Windows Media Player Firefox plug-in installed in order to reproduce the bug (http://port25.technet.com/pages/windows-media-player-firefox-plugin-download.aspx). > > Here is the relevant markup served to Safari: > > <object classid="clsid:6BF52A52-394A-11D3-B153-00C04F79FAA6" type="application/x-ms-wmp" ...> > > Prior to r70559, we obeyed the type attribute and ignored the classid attribute, and we'd load the WMP plug-in. r70559 implemented HTML5's specified behavior for when a non-empty classid is encountered, which is to fall back when we don't recognize the classid (and after r70559, we don't recognize any classids). No plug-in loads in this case, which is correct behavior according to the spec. > > This page works in Firefox because Firefox is served an object tag with the classid attribute omitted, so a plug-in is loaded based on the contents of the type attribute. This is what the page should be serving to Safari and Chrome as well, as it would work reliably before or after r70559. > > This is best resolved by evangelizing the site to serve WebKit UA's the Firefox-style markup that omits IE-specific classids. I don't think we want to go back down the road of mapping classids to MIME types. D'oh! Except for in the first paragraph, replace all mentions of r70599 with r70748.
Interesting, thanks for investigating this! i have my own "D'oh!" for not thinking about the lagging builds possibility...
*** Bug 48885 has been marked as a duplicate of this bug. ***
Created attachment 72771 [details] Test case Attached is a test case that demonstrates the same issue that we see on the site. You'll need Flip4Mac installed on the Mac or WMP for Firefox installed on Windows for this to work properly. In Safari 5, you should see a video with the text "support.microsoft.com"; in Safari ToT, you should see the word "FAIL".
<rdar://problem/8623789>
I uploaded a test case for completeness' sake, but I think this should be treated as an evangelism issue.
While I agree about this being an evangelism issue, perhaps we can improve compat by honoring the mime type if it is specified in the object tag.
(In reply to comment #9) > While I agree about this being an evangelism issue, perhaps we can improve compat by honoring the mime type if it is specified in the object tag. Perhaps we should address this by filing a bug against the HTML5 spec. The current draft specifies that mime type shouldn't be considered when a non-empty classid is present, but perhaps changing this restriction would be better for compatibility. I can do this, but first I'd be curious to know if there's been previous discussion about this issue on whatwg or public-html.
nana10 have fixed their site. Andy: Should we leave this bug open to track suggesting a spec change or should we close this and file a new bug?