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

RESOLVED FIXED in mozilla1.9alpha8

Status

()

Core
Plug-ins
P1
major
RESOLVED FIXED
10 years ago
10 years ago

People

(Reporter: dria, Assigned: bz)

Tracking

({regression})

Trunk
mozilla1.9alpha8
regression
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

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.
Summary: Flash video not appearing → revver flash video not playing
Flags: blocking1.9?

Comment 3

10 years ago
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.
Blocks: 1156
Component: General → Plug-ins
Keywords: regression
OS: Mac OS X → All
QA Contact: general → plugins
Hardware: Macintosh → All
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
Assignee: nobody → english-us
Component: Plug-ins → English US
Flags: blocking1.9?
Product: Core → Tech Evangelism
QA Contact: plugins → english-us
Version: Trunk → unspecified
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. :(
Whiteboard: [wanted-firefox3]

Comment 10

10 years ago
(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... ;-)
Priority: -- → P1
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
Severity: major → 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.
Assignee: english-us → nobody
Severity: blocker → major
Component: English US → Plug-ins
Product: Tech Evangelism → Core
QA Contact: english-us → plugins
Whiteboard: [wanted-firefox3]
Version: unspecified → Trunk
Flags: blocking1.9?
Summary: revver flash video not playing → flash video sent with incorrect content-type no longer works
Summary: flash video sent with incorrect content-type no longer works → flash video that uses <object> and incorrect content-type no longer works
Priority: P1 → --
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.)
Priority: -- → P1
I'm actually surprised that anyone's doing this, since it doesn't work in IE... They must be doing some serious sniffing.  :(
Created attachment 276033 [details] [diff] [review]
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....
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Attachment #276033 - Flags: superreview?(cbiesinger)
Attachment #276033 - Flags: review?(cbiesinger)
It'd also be nice if we had testcases for all that stuff I tested... but we don't.
Flags: in-testsuite?
Summary: flash video that uses <object> and incorrect content-type no longer works → [FIX]flash video that uses <object> and incorrect content-type no longer works
Target Milestone: --- → mozilla1.9 M8
Comment on attachment 276033 [details] [diff] [review]
Say like this
Attachment #276033 - Flags: superreview?(cbiesinger)
Attachment #276033 - Flags: superreview+
Attachment #276033 - Flags: review?(cbiesinger)
Attachment #276033 - Flags: review+
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.
Attachment #276033 - Flags: approval1.9?

Updated

10 years ago
Blocks: 390891
Attachment #276033 - Flags: approval1.9? → approval1.9+
Checked in.  Need tests, though....  Help writing those would be great.  :(
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Flags: blocking1.9?
Resolution: --- → FIXED
Depends on: 395533
You need to log in before you can comment on or make changes to this bug.