810494 - Objects/embeds with a known mime type shouldn't trigger plugin errors

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[John Schoenick [:johns]]

A tag as such:

> <embed type="image/png">

Will trigger a missing plugin error, which is obviously bogus. Bug 548133 will expand this issue to object tags, causing some test failures

Comment 1

[John Schoenick [:johns]]

Attachment: Don't show plugin errors for types we recognize but are not loading for another reason

Comment 2

[John Schoenick [:johns]]

Comment on attachment 680257 [details] [diff] [review]
Don't show plugin errors for types we recognize but are not loading for another reason

Okay the try run failures were due to pushing the wrong patch, this is ready for review after all.

Comment 3

[John Schoenick [:johns]]

Comment on attachment 680257 [details] [diff] [review]
Don't show plugin errors for types we recognize but are not loading for another reason

https://hg.mozilla.org/integration/mozilla-inbound/rev/9e50e8c6c5cf


Try:
https://tbpl.mozilla.org/?tree=Try&rev=7ac49c949717

Comment 4

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/9e50e8c6c5cf

Comment 5

[John Schoenick [:johns]]

Comment on attachment 680257 [details] [diff] [review]
Don't show plugin errors for types we recognize but are not loading for another reason

[Approval Request Comment]
Bug caused by (feature/regressing bug #):
Unknown, rather old behavior

User impact if declined:
Tags such as <embed type="text/html">, that are of a valid type but lack a URI, will display a missing-plugin error, which is obviously bogus. (but have done so since at least 15, likely longer)

Testing completed (on m-c, etc.):
On m-c

Risk to taking this patch (and alternatives if risky): 
Low, removes uncommon but bogus behavior unique to FF, might change display of sites doing odd things.

String or UUID changes made by this patch:
None

This blocks landing bug 800018 on beta

Comment 6

[John Schoenick [:johns]]

Comment on attachment 680257 [details] [diff] [review]
Don't show plugin errors for types we recognize but are not loading for another reason

[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration:
This is needed if we want to take bug 800018 on 17esr, otherwise is not worth uplifting. See comments there.

Comment 7

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/f800cff693d6
https://hg.mozilla.org/releases/mozilla-beta/rev/fc9677f8a2f6
https://hg.mozilla.org/releases/mozilla-esr17/rev/b49489fb8164

Comment 9

[John Schoenick [:johns]]

bug 817981 points out that this was fixed by 745030 and then regressed at some point before being fixed again, going to add a test case here.

Comment 10

[John Schoenick [:johns]]

Attachment: Test

Comment 11

[John Schoenick [:johns]]

Comment on attachment 688494 [details] [diff] [review]
Test

Err, actually, this would work just fine as a content mochitest

Comment 12

[John Schoenick [:johns]]

Attachment: Test

Makes sure that loading non-plugin types into these tags always ends up using
alternate content, rather than plugin-specific error modes

Comment 13

[John Schoenick [:johns]]

Comment on attachment 688500 [details] [diff] [review]
Test

https://hg.mozilla.org/integration/mozilla-inbound/rev/704d7d2ac810

Comment 14

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/704d7d2ac810