263756 - corrupt object tag fools Plugin Finder

Status: RESOLVED WONTFIX

(Toolkit Graveyard :: Plugin Finder Service, defect)

Description

[Aaron Slunt]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041010 Firefox/0.10.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041010 Firefox/0.10.1

A corrupt <object> tag has the capability of making Firefox think there's a
missing plugin, and the notice will come up and such, and then no plugin is found. 

<object data="" type="image/">blah</object> is an example. Firefox sees an
unknown mime type, gets confused, and ends up saying there's a missing plugin.

Reproducible: Always
Steps to Reproduce:
1.Go to the testcase supplied.
2.
3.

Actual Results:  
Plugin Finder Bar appears; no plugins can be found.

Expected Results:  
Ignore the problematic object tag and do nothing with it.

Comment 1

[Aaron Slunt]

Attachment: plugin testcase

Testcase that tricks the plugin finder.

Comment 2

[Doron Rosenberg (IBM)]

jst: can nsObjectFrame figure out if its trying to display something other than
a plugin?

Comment 3

[Johnny Stenback (:jst)]

I don't know what the logic could be here. We can't really make anything but a
bad guess based on a mimetype we don't support... Does anyone else have any
ideas here?

Comment 4

[Boris Zbarsky [:bzbarsky]]

Well, we could do minimal validity checking on the MIME type.  But using
"image/x", say _should_ give us the plugin finder, right?

Comment 5

[Aaron Slunt]

That's what I was thinking: have Firefox check to make sure that it is a
possible mime-type, by making sure there are x amount of characters after the /
in the mime type. That seems logical to me.

Comment 6

[Boris Zbarsky [:bzbarsky]]

You mean "at least one character", right?

Comment 7

[Aaron Slunt]

That could work, but there's really no mime-type in existance that is only one
character, which is why I said x amount; maybe 4 (the shortest mime-type i can
think of is "/jpeg"

Comment 8

[Boris Zbarsky [:bzbarsky]]

New MIME types get created all the time; anyone can make one up.  So hardcoding
assumptions about them (assumptions not grounded in the relevant RFC) is a
really bad idea.

Comment 9

[Aaron Slunt]

Well then, you're idea is better; to make sure there is SOMETHING after that /

Comment 10

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

I'm not sure this would be worth the code.... very few people specify such an
invalid mimetype, I suppose.

Comment 11

[Aaron Slunt]

Think of what the user would  see though: a webmaster accidentally borks up the
mime type in the object tag, by not including anythign after /, and then the
user sees "Install Missing Plugins" then they go to do so, and find nothing is
available to install, then they go "OMG FIREFOX SUX IE RULES" because of a
simple mistake that is messing with the plugin finder.

Comment 12

[Johnny Stenback (:jst)]

(In reply to comment #11)
> Think of what the user would  see though: a webmaster accidentally borks up the
> mime type in the object tag, by not including anythign after /, and then the
> user sees "Install Missing Plugins" then they go to do so, and find nothing is
> available to install, then they go "OMG FIREFOX SUX IE RULES" because of a
> simple mistake that is messing with the plugin finder.

What makes you think IE would display something if the mimetype is incorrect?

Comment 13

[Aaron Slunt]

I never said IE would display anything; in fact, it doesn't, and if someone who
wants to try FF before switching, runs into this, they might think FF sucks, and
go back to IE.

Comment 14

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

is this kind of mistake any more likely than (say) image/x (with something after
the slash)?

Comment 15

[Aaron Slunt]

Yes, it is. For example, let's say someone uses PHP to determine the mime-type
to put on an object tag. Like it has "blah.jpg," and you use

$ext=explode('.','blah.jpg');

$imgext=$ext[1]=='jpg' ? 'jpeg':$ext[1];

What this does is turn jpg into jpeg for the mime type, and if it's a different
object, such as gif, it leaves that. So then you get

<object data="blah.jpg" type="image/' .$imgext. '" />

Now, let's say that for some reason (maybe selecting the image from the database
or whatever), that the $imgext doesn't show up. The plugin finder will go nuts
then, as only "image/" will show up.

A simple coding error like this is far more likely than just one character: if
there's only 1 character, then it's pretty clear that it was intentional to set
a mime-type like that: but if there's nothing, then it's most likely a mistake,
and this is very likely to occur.

Comment 16

[Johnny Stenback (:jst)]

I'm sorry, but I don't buy it. I'd be fine with making the plugin finder service
page that you'd get to when you click on the "Find out more..." link on the last
page of the plugin finder wizzard contain some sort of logic to advice the user
based on the mimetype that the webpage that this plugin reference was found on
is busted, but I really don't think any code like that belongs in the browser.
And I don't see this driving away users at all, at least not more than some
totally insignificant number.