Bug 24547
| Summary: | src of embed elements are downloaded when no plugin exists to handle them | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Xan Lopez <xan.lopez> |
| Component: | Page Loading | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | gustavo |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| URL: | http://www.publico.es | ||
Xan Lopez
Go to www.publico.es, 6 download dialogs will be opened with filename "small%20type=". Seems like content sniffing is not worknig totally OK.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Gustavo Noronha (kov)
From what I investigated up to now, the problem here is that our frame loader client by default decides to download anything canShowMIMEType says webkit can't handle. So Xan hits this problem because he has no flash plugin installed. Our policy sounds wrong, though. We should probably be ignoring those subresources we don't know how to display, instead of downloading them.
Gustavo Noronha (kov)
This is more general than what we first thought; the problem is webcore handles whatever the src attribute of element tags as normal resources, so if there is no plugin available to handle that content type, we end up downloading it. And it looks like downloading whatever is unknown is the right thing to do; at least some sites seem to depend on it (sourceforge, for instance).
I asked around in #webkit and confirmed same happens to Safari if you uninstall the flash plugin and go to that page, so this looks like an issue to be fixed in WebCore itself.
It seems like Firefox has a default plugin that catches all content types built in, so it is able to not cause those download requests to happen, and at the same time present a nice dialog offering to download the missing plugin.