389677 - [FIX]flash video that uses <object> and incorrect content-type no longer works

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect, P1)

Description

[Deb Richardson [:dria] (plz NEEDINFO)]

Went to view the latest "Will it Blend?" but the video is not being displayed in Minefield (see URL).  Works OK in Fx2.0.0.5.  YouTube videos and such still work fine, as well.

Comment 1

[Mike Beltzner [:beltzner, not reading bugmail]]

I can confirm this in Windows (through Parallels) as well, though it was working for me on a recent (like, two or three days old, 20070723 at oldest) OSX nightly that was being updated via the "nightly" channel. When I updated to the latest nightly, it broke.

What's odd, though, is that if I download an older nightly - like 20070720 - even when running with a fresh profile it remains broken.

Comment 2

[Mike Beltzner [:beltzner, not reading bugmail]]

Seems highly localized to flash video served up from revver.com. Video from Google Video, YouTube, metacafe, ifilm, TED, and pretty much any other flash-video site I could find still seems to work.

Comment 3

[Adam Guthrie]

Had to use my wayback machine for this regression range, but it regressed between 2005-09-21-07 and 2005-09-22-08, making it a regression from bug 1156.

Comment 4

[Christian :Biesinger (don't email me, ping me on IRC)]

This is working as designed... The site sends application/octet-stream as the content type for the flash <object>, and HTML specifies that the server-sent type takes precedence over a type attribute (if any). bug 1156 made us implement that part of HTML correctly.

Comment 5

[Christian :Biesinger (don't email me, ping me on IRC)]

-> tech evang

Comment 6

[Mike Beltzner [:beltzner, not reading bugmail]]

I'm absolutely positive that I had revver flash video displaying in a trunk build properly this morning at the same time that dria's was broken, but maybe I was getting to a different revver server that doesn't have the broken HTML?

Very strange, but possible, I guess.

Comment 7

[Christian :Biesinger (don't email me, ping me on IRC)]

Is it possible that you had changed your user-agent not to include Gecko in the case where this worked for you by chance? (In such a case, the page uses a different codepath that still works).

Comment 8

[Mike Beltzner [:beltzner, not reading bugmail]]

Not unless it changed during the update, and then didn't change back.

Comment 9

[Mike Beltzner [:beltzner, not reading bugmail]]

Is there any way to nominate a tech evangelism bug for blocking status? While this might be us complying to a spec, we're currently the only browser that doesn't work with Revver video. :(

Comment 10

[Bob Clary [:bc] (inactive)]

(In reply to comment #9)
> Is there any way to nominate a tech evangelism bug for blocking status? 

Nope. I suggest that an official contact from schrep or someone else with name-brand recognition such as yourself contact them. If you would rather, I can use my moco addy to contact them. Depending on their maintenance schedule it shouldn't be a problem to get this fixed before Firefox 3 releases... ;-)

Comment 11

[Mike Beltzner [:beltzner, not reading bugmail]]

Another major site where Flash video isn't working is General Motors Canada:

http://www.gmcanada.com/gm/english/vehicles/chevrolet/uplander/overview

Are we *sure* this is tech evangelism? It feels like something we need to be more forgiving of.

status --> blocker

Comment 12

[:Gavin Sharp [email: [e-mail]]]

It looks like the flash file on the GM site is sent as text/plain. It seems fairly common for sites to send the wrong content type. I think we should reconsider the change that made us give up on unknown content types given the high-profile sites that are breaking because of it.

Comment 13

[Boris Zbarsky [:bzbarsky]]

I could live with falling back on the "type" attribute if the channel type is application/octet-stream (and in fact I think this is a really good idea) or maybe even the sniffed binary type (to handle the GM mess-up), and we can stick our text-or-binary sniffer in there to sniff for binary.  Would that cover any "legitimate" cases of bogus types?  I think so...  I think it would also break non-ASCII text documents in <object> when served from Apache.  But given that we also break them in uriloader... maybe that's ok.  We'd need similar server checks here, of course.

Have I mentioned how much I hate the web lately?  ;)

Comment 14

[Mike Beltzner [:beltzner, not reading bugmail]]

(To be clear, I think we should reach out to revver as well - I'm just thinking that the web, hateful place that it is, might not react well to us being suddenly strict here, especially where no-one else is.)

Comment 15

[Boris Zbarsky [:bzbarsky]]

I'm actually surprised that anyone's doing this, since it doesn't work in IE... They must be doing some serious sniffing.  :(

Comment 16

[Boris Zbarsky [:bzbarsky]]

Attachment: Say like this

Basic idea:

* Change the text/plain sniffing to use an nsIContentSniffer
* Change <object> loads to call sniffers
* Use the original type hint if the channel type in OnStartRequest is either
  sniffed-binary or application/octet-stream.

I tested that the URI in bug https://bugzilla.mozilla.org/show_bug.cgi?id=226024 still gets sniffed as binary.  I also tested that the feed sniffer now works for <object>.  Oh, and we still pass Acid2.

This fixes both of the testcases in this bug, and shouldn't break anything reasonable, I don't think....

Comment 17

[Boris Zbarsky [:bzbarsky]]

It'd also be nice if we had testcases for all that stuff I tested... but we don't.

Comment 19

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 276033 [details] [diff] [review]
Say like this

Requesting approval.  This patch makes us sniff certain text/plain responses for <object> to see whether they might actually be binary (just like we do for <iframe>), and makes us treat binary-sniffed and application/octet-stream responses per the content-type attribute of the object, if any.  This should significantly improve web compat by covering the most common broken MIME type cases without breaking any legitimate content, I hope.

Comment 20

[Boris Zbarsky [:bzbarsky]]

Checked in.  Need tests, though....  Help writing those would be great.  :(