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

VERIFIED FIXED

Status

()

Core
Plug-ins
P2
normal
VERIFIED FIXED
10 years ago
10 years ago

People

(Reporter: Martijn Wargers (dead), Assigned: jst)

Tracking

({regression, testcase})

Trunk
x86
Windows XP
regression, testcase
Points:
---
Bug Flags:
blocking1.9 +
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(4 attachments, 1 obsolete attachment)

(Reporter)

Description

10 years ago
Created attachment 278284 [details]
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).
(Reporter)

Updated

10 years ago
Attachment #278284 - Attachment mime type: application/x-shockwave-flash → application/octet-stream
(Reporter)

Updated

10 years ago
Attachment #278284 - Attachment is obsolete: true
(Reporter)

Comment 1

10 years ago
Created attachment 278286 [details]
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?
(Reporter)

Comment 2

10 years ago
Ah, ok, the bogus type isn't necessary to see the bug.
Which bogus type?  The attribute?
Flags: blocking1.9?
(Reporter)

Comment 4

10 years ago
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".

Comment 6

10 years ago
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?
(Reporter)

Comment 8

10 years ago
Created attachment 278321 [details]
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.
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

10 years ago
(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

(Reporter)

Comment 11

10 years ago
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?
(Reporter)

Comment 14

10 years ago
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
Blocks: 1156

Updated

10 years ago
Assignee: cbiesinger → jst
Flags: tracking1.9+ → blocking1.9+
Priority: P3 → P2
(Assignee)

Comment 20

10 years ago
Created attachment 311867 [details]
Same as the first testcase but w/o the bogus type attribute.
(Assignee)

Comment 21

10 years ago
Created attachment 311870 [details] [diff] [review]
Get the mimetype from the extension if all else fails.
Attachment #311870 - Flags: superreview?(bzbarsky)
Attachment #311870 - Flags: review?(bzbarsky)
Comment on attachment 311870 [details] [diff] [review]
Get the mimetype from the extension if all else fails.

Yeah, looks good.
Attachment #311870 - Flags: superreview?(bzbarsky)
Attachment #311870 - Flags: superreview+
Attachment #311870 - Flags: review?(bzbarsky)
Attachment #311870 - Flags: review+
(Assignee)

Comment 23

10 years ago
Fix checked in. If we need other bugs on issues beyond what this patch fixes, please open new bugs.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Flags: in-testsuite?
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.