Closed Bug 393756 Opened 15 years ago Closed 14 years ago
Flash ad doesn't show up, embed with bogus type and application/octet-stream mime-type
375 bytes, text/html
602 bytes, text/html
340 bytes, text/html
1.62 KB, patch
|Details | Diff | Splinter Review|
See the ad at the top. I only see the plugin placeholder with current trunk build, but I can see the ad just fine with branch builds. If wanted, I can look for a regression range (I suspect at the end of 2005, though).
Attachment #278284 - Attachment mime type: application/x-shockwave-flash → application/octet-stream
Attachment #278284 - Attachment is obsolete: true
It doesn't seem to be possible to attach the flash file to the bug. It seems like Mozilla used to sniff the extension of the file too to find out if it's a flash file?
Ah, ok, the bogus type isn't necessary to see the bug.
Which bogus type? The attribute?
Yes, I meant the bogus type attribute, but that isn't actually important for the testcase.
It works if you give the embed the correct "type" right? Does this site not do that? Frankly, if they _list_ a bogus type like that I don't think it should "work".
WFM using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007082604 Thunderbird/3.0a1pre ID:2007082604 Which would mean it's not a problem with core-plugins. As I recall, the file sniffing to over-ride the application-octet stream will only work if windows holds a file association to the file extension. Can't remember the bug, but had to do with "known file types"
How exactly are you testing a random HTML page with Thunderbird?
(In reply to comment #5) > It works if you give the embed the correct "type" right? Does this site not do > that? Yes, that works. Indeed this site does not do that. It uses type="application/plugin-mimetype". > Frankly, if they _list_ a bogus type like that I don't think it should "work". I guess so. But it used to work, so this might give more problems.
I suppose we could look for a plug-in by extension after we fail to find one by type... but I'd rather not do that unless this is at least somewhat common. This site we should evangelize no matter what. On the other hand, removing the type should perhaps work (that is, we should consider getting the type hint by extension if there's no type attr and the server sends octet-stream).
(In reply to comment #7) > How exactly are you testing a random HTML page with Thunderbird? > By using: <embed src="http://resources.eyereturn.com/002054_v2_pumps_sleeping_728x90.swf" type="application/plugin-mimetype" height="90"> in a message/send later, then open the message. Since this works for me, I think that eliminates the posibility of core-plugin problem. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007082604 Thunderbird/3.0a1pre ID:2007082604
I had to set mailnews.message_display.allow.plugins to true (and allow html mail), but indeed, for some reason it works when viewinging in current trunk Thunderbird.
Odd. I don't think it should, based on the code.
an objlc:5 log of thunderbird might be interesting, but perhaps this works because (I assume) thunderbird disables the pluginfinder, so the objectloadingcontent code attempts to instantiate the nullplugin, but the plugin code finds the flash plugin?
Another site that suffers from the same issue: http://www.canada.com/topics/sports/story.html?id=5dbd04a4-94bd-4ca3-a064-0a36f59d1845&k=80634 And this one also uses type="application/plugin-mimetype" as attribute.
So... why are people doing this? Is it people misunderstanding the devedge docs, which use that string as a placeholder for the actual type of the data? I guess we could look up the type based on the URI if @type is this magic value. That feels like such a major hack that I'd really like to avoid it, though.
What did we do before when this worked? What biesi says in comment 13? This seems bad that we have regressed, so we probably need to do something. Boris, would you have the cycles to fix this? If not maybe biesi would?
Assignee: nobody → bzbarsky
Flags: blocking1.9? → blocking1.9+
> What did we do before when this worked? No idea. The old code did all sorts of stuff with extensions that we don't generally want to do anymore. > Boris, would you have the cycles to fix this? Pretty unlikely given my other existing blockers and non-Mozilla commitments....
Biesi, could you have a go at this one?
Assignee: bzbarsky → cbiesinger
Priority: -- → P3
Biesi: any updates? I'd be fine with saying that we shouldn't do anything here, other than to add documentation. Though it does seem like a good idea to do what boris says in the second paragraph of comment 9. That would at least give is a good fix to point authors at. I'm gonna go ahead and guess that this is a regression from bug 1156
Assignee: cbiesinger → jst
Flags: tracking1.9+ → blocking1.9+
Priority: P3 → P2
Comment on attachment 311870 [details] [diff] [review] Get the mimetype from the extension if all else fails. Yeah, looks good.
Fix checked in. If we need other bugs on issues beyond what this patch fixes, please open new bugs.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
verified fixed using the testcases and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008041217 Minefield/3.0pre ID:2008041217 - flash works fine. --> verified fixed
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.