Bug 48757 – REGRESSION (r70748): Live video does not work on 10tv.nana10.co.il

• Component: Plug-ins
• Status: RESOLVED WONTFIX

[Yair Yogev]

*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

[Carlos Pizano-Uribe]

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.

[Andy Estes]

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.

[Andy Estes]

(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.

[Yair Yogev]

Interesting, thanks for investigating this!
i have my own "D'oh!" for not thinking about the lagging builds possibility...

[Andy Estes]

*** Bug 48885 has been marked as a duplicate of this bug. ***

[Andy Estes]

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".

[Andy Estes]

<rdar://problem/8623789>

[Andy Estes]

I uploaded a test case for completeness' sake, but I think this should be treated as an evangelism issue.

[Ananta Iyengar]

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.

[Andy Estes]

(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.

[Jeremy Moskovich]

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?