393756 - Flash ad doesn't show up, embed with bogus type and application/octet-stream mime-type

Status: VERIFIED FIXED

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

Description

[Martijn Wargers (dead)]

Attachment: flash needed for testcase

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

Comment 1

[Martijn Wargers (dead)]

Attachment: testcase

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?

Comment 2

[Martijn Wargers (dead)]

Ah, ok, the bogus type isn't necessary to see the bug.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Which bogus type?  The attribute?

Comment 4

[Martijn Wargers (dead)]

Yes, I meant the bogus type attribute, but that isn't actually important for the testcase.

Comment 5

[Boris Zbarsky [:bzbarsky]]

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

Comment 6

[Joe Sabash [:JoeS1]]

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"

Comment 7

[Boris Zbarsky [:bzbarsky]]

How exactly are you testing a random HTML page with Thunderbird?

Comment 8

[Martijn Wargers (dead)]

Attachment: testcase2

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

Comment 9

[Boris Zbarsky [:bzbarsky]]

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

Comment 10

[Joe Sabash [:JoeS1]]

(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

Comment 11

[Martijn Wargers (dead)]

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.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Odd.  I don't think it should, based on the code.

Comment 13

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

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?

Comment 14

[Martijn Wargers (dead)]

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.

Comment 15

[Boris Zbarsky [:bzbarsky]]

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.

Comment 16

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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?

Comment 17

[Boris Zbarsky [:bzbarsky]]

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

Comment 18

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Biesi, could you have a go at this one?

Comment 19

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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

Comment 20

[Johnny Stenback (:jst)]

Attachment: Same as the first testcase but w/o the bogus type attribute.

Comment 21

[Johnny Stenback (:jst)]

Attachment: Get the mimetype from the extension if all else fails.

Comment 22

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 311870 [details] [diff] [review]
Get the mimetype from the extension if all else fails.

Yeah, looks good.

Comment 23

[Johnny Stenback (:jst)]

Fix checked in. If we need other bugs on issues beyond what this patch fixes, please open new bugs.

Comment 24

[Carsten Book [:Tomcat]]

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