Closed Bug 316418 Opened 19 years ago Closed 14 years ago

Missing Plugins for mimetype text/html

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: frenchfrog, Unassigned)

References

(
URL
)

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051113 Firefox/1.5 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051113 Firefox/1.5 The "Additonnal plugins are required to display that page." appear at the top of Firefox when browsing http://www.xanga.com/ranaenergy, clicking "Install Missing plugins..." don't found anything because it seems to be searching (mimetype text/html). (More infos to know what mimetype is missing in bug 264282 comment 8) Firefox should never search for text/html plugins. Reproducible: Always Steps to Reproduce:
Version: Trunk → 1.8 Branch
The offending HTML code at the site you quoted is: <embed src="http://ciaraworld.com" autostart="true" hidden="true"> So, what do you expect Firefox to do when a site requests to embed an HTML document (that's what is returned when requesting the given URL) in a page? EMBED explicitly requests handling by a plugin, so IMHO the site is broken and this is not a bug in Firefox.
I agree that the site is broken but I don't think Firefox should give me a "Additonnal plugins are required to display that page." if mimetype text/html don't make any sense.
EMBED is a way to add _alien_ data in a page and I don't think it always 'explicitly requests handling by a plugin', take the case of SVG for exemple.
interesting that you mention this... originally, SVG didn't work in embed either (unless adobe's plugin was installed, of course) Codewise, it's trivial to allow all type of content in <embed>, but we have limited us to plugins, SVG and images... anyone know why?
OS: Windows XP → All
Hardware: PC → All
Version: 1.8 Branch → Trunk
For compat reasons, basically. I don't believe any other major browser shows non-plugin stuff via <embed>, for the same reasons.
*** Bug 321227 has been marked as a duplicate of this bug. ***
?? that absolutely shouldn't have changed anything in this respect... (at least, compared to 1.8)
So the regression of this bug is the patch for bug 309521?
OK, after over 5 years I can confirm this bug. The bug is reproducible both using: 1 - <embed src="http://someurl.com/"> than: 2 - <object data="http://someurl.com"> <embed src="http://someurl.com"></object> Testcase to reproduce case 1 ==> http://downloadresources.forumcommunity.net/?t=43868474 Testcase to reproduce case 2 ==> http://www.web-source.net/embedding_web_pages.htm
Status: UNCONFIRMED → NEW
Ever confirmed: true
We're going to leave the current behavior. The pages in question should use <object> (which will use the builtin HTML renderer), instead of <embed>, which is specifically for plugins.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
I (In reply to comment #10) Tested with Firefox 3.6.x on Windows XP. Just FYI, Google Chrome 9.x manages both URLs correctly.
We do manage it correctly. We don't render the content ourselves and tell you that if you want to render it you need a plug-in for text/html. If you had such a plug-in, it would be used to render the <embed>.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.