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.

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.

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.

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.

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.

-> tech evang

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.

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

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

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

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

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

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.

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? ;)

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

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

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

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

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.

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