spin-off from bug 294800: > buffer.AppendLiteral(... > "<link rel=\"icon\" type=\"image/png\" href=\""); > //XXX can't use skinnable icons here due to security restrictions > if (isSchemeRemote) { > //buffer.AppendLiteral("chrome://global/skin/dirListing/remote.png"); > buffer.AppendLiteral("data:image/png;base64,..."); > } else { > //buffer.AppendLiteral("chrome://global/skin/dirListing/local.png"); > buffer.AppendLiteral("data:image/png;base64,..."); > } > buffer.AppendLiteral("\" />\n<title>"); When using a chrome URI, the favicon isn't loaded and the error console says: "Security Error: Content at http://ftp.mozilla.org/pub/mozilla.org/ may not load or link to chrome://global/skin/dirListing/remote.png."

Related to/dupe of bug 301119?

Bug 301119 is remotely related. FTP/File/Jar dir listings are built through streamconv. As far as I can tell, that's significantly different from error pages.

Comment on attachment 272779 [details] [diff] [review] loosen restrictions this is tested for ftp, file, jar and gopher dir listings with a modified version of the patch for bug 294800. I've used a local html file to verify that |fileName == ""| works.

In case this won't be fixed, the icons should be removed from the theme packages.

Can't we just set some class on the affected <tr> or <td> and let the theme set the icon there via CSS?

This bug is about <link rel="icon"...>, not the listing table itself.

Ah, right. Still this appears in the theme, and hardcoded paths for theme icons also suck. I guess we may not be able to do without them though in this case...

That patch doesn't work for jar: listings, does it? In general, any time a patch is hardcoding schemes it's buggy...

Why not replace the literal URIs with code to sync-read data from a chrome:// URI and create the data: URI on the fly? That would make this themable without requiring us to poke holes in our security policy.

(In reply to comment #10) > That patch doesn't work for jar: listings, does it? I'm not sure if I tested jar explicitly, but schemeIs("jar") && fileName == "" is true, so I suppose it does work. (In reply to comment #11) > Why not replace the literal URIs with code to sync-read data from a chrome:// > URI and create the data: URI on the fly? That's probably too much for me to handle, I barely know C++ after all. I agree that it sounds safer, but I won't be the assignee then.

Comment on attachment 272779 [details] [diff] [review] loosen restrictions Actually this patch is wrong, as dir listing URLs don't have to end with a slash, which means that fileName isn't necessarily empty.

(In reply to comment #13) > (From update of attachment 272779 [details] [diff] [review]) > Actually this patch is wrong, as dir listing URLs don't have to end with a > slash, which means that fileName isn't necessarily empty. Additionally, proxy servers often serve custom HTML for ftp dir listings, so this is really not the way to go.

This bug's priority relative to the set of other polish bugs is: P5 - Polish issue that is rarely encountered, and is not easily identifiable. These icons are incorrect, but users don't that commonly use ftp/file/jar listings, and those that do are not that likely to consciously notice that they are seeing an aero icon when they should be seeing a tango icon, etc.