1428271 - provide api to get system file icons (moz-icon replacement)

Status: RESOLVED WONTFIX

(WebExtensions :: General, defect, P5)

Description

[pea3nut]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20180103231032

Steps to reproduce:

I want to use moz-icon in extension. I find it no longer supports in fx59a1.

This code is works in fx58b14 but not works in fx59a1.
<img src="moz-icon://.pdf?size=128" alt="" width="128">


Actual results:

Extension page cannot use moz-icon.


Expected results:

I want to use moz-icon in extension, and more, I'd like use Ajax or Fetch API to do that get file icon.

Comment 1

[CosminB]

Attachment: Bug1428271.png

I can reproduce this issue on Firefox 59.0a1 (20180105100137) under Win 7 64-bit and Mac OS X 10.13.1

Please see the attached screenshot.

I did a regression window and observed that Bug 1222924 is the one makes moz-icon to not work:

Last good revision: ee15ca302afd49b17397039ad07c9e249fd0aa97
First bad revision: ec15d17d85cb9423cd45fa19069d831c4c563d8c
Pushlog:https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=ee15ca302afd49b17397039ad07c9e249fd0aa97&tochange=ec15d17d85cb9423cd45fa19069d831c4c563d8c

Comment 2

[pea3nut]

I found moz-icon:file://path/to/file.ext is already not worked in fx58b14 and 57.0.4, but moz-icon://.ext is worked.

Comment 3

[Mike Taylor [:miketaylr]]

Freddy, is this bug invalid? Bug 1222924 removed support for moz-icon from the web... not sure what the status is for web extensions.

Comment 4

[Frederik Braun [:freddy]]

I'm not sure my answer is authoritative here, but I'd like us to stop support moz-icon in general.
We could offer something else (see other bug) for WebExtensions, if we want to make a conscious decision about this being a valuable feature for Web Extensions.

Comment 5

[pea3nut]

I'm making a extenstion which can open local file as user want. The moz-icon provide a shortcut to get any file icon, whether the file has icon self or not.(In windows, the .exe file is allowed has a icon).
If don't have the moz-icon, It maybe move complex than extenstion self that how to get any file icon.

Comment 6

[:Gijs (he/him)]

This could be fixed by adding another escape hatch to nsScriptSecurityManager for webextension principals, but I'm pretty reluctant to do that. If we do do something like that, I'd really like to restrict it to forms of moz-icon that only have an extension (not a file URI).

Note that on macOS, this will already fail in sandboxed processes anyway. I'm not convinced the risk/reward balance is right to try to go around that. We should avoid adding more ways of effectively breaking out of any sandboxing we offer.

Does Chrome offer anything in this space? Of course, it's trivially possible to work around this by the add-on shipping icons for the file extensions (or applications) it offers access to. All of this is then further complicated by the fact that the webextension vs. file interaction still hasn't been fully worked out, AFAICT. So yeah. I'm thoroughly unenthusiastic about fixing this, but I'm not up-to-date on the ramifications here, how many add-ons depend on this, and in what circumstances (and what, if any, alternatives they have in Chrome/Opera/whatever).

Comment 7

[pea3nut]

How about add a new permissions key in manifest.json for use moz-icon?
I think it is requisite for WebExtentions that be accessed a file. see bug 1428268. As far as I am concerned, if I can get file real path and icon, I needless use the underlying moz-icon. But, I heartfelt think it's a awesome feature that open moz-icon for WebExtentions.

Comment 8

[Andrew Overholt [:overholt]]

As an outsider to this discussion, this feels less like a traditional regression and more like an enhancement request so I'm tempted to remove the regression keyword (we have a slightly enhanced process for bugs tagged as regressions). Would that be super annoying to anyone involved here?

Comment 9

[pea3nut]

It doesn't matter to me. I just want use moz-icon in Webextensions.

Comment 10

[Caitlin Neiman [:caitmuenster]]

Hi pea3nut, this has been added to the agenda for the WebExtensions APIs triage on April 10, 2018. Would you be able to join us? 

Here’s a quick overview of what to expect at the triage: 

* We normally spend 5 minutes per bug
* The more information in the bug, the better
* The goal of the triage is to give a general thumbs up or thumbs down on a proposal; we won't be going deep into implementation details

Relevant Links: 

* Wiki for the meeting: https://wiki.mozilla.org/WebExtensions/Triage#Next_Meeting
* Meeting agenda: https://docs.google.com/document/d/1cFcqNOLwp77aosh5QUeNKgW8FQONAzOBlqjbcbxdIXw/edit#
* Vision doc for WebExtensions: https://wiki.mozilla.org/WebExtensions/Vision

Comment 11

[pea3nut]

I really want to go, but the English prevent me - my English is bad. 

@bzhao Would you be able to go?

Comment 12

[Caitlin Neiman [:caitmuenster]]

This proposal was denied during the design decision meeting; Rob will follow-up with more detail about the decision and a possible workaround solution.

Comment 13

[Rob Wu [:robwu]]

"moz-icon" protocol won't be exposed to WebExtensions (comment 4 and comment 6), so providing the functionality would require the implementation of a new WebExtension API.

We have decided to not build such an API, because of the implementation efforts, the limited use cases and the fact that an extension can approximate the functionality by including the icons for supported file formats in an extension package.

For example, you could get the icons from https://github.com/KDE/oxygen-icons (stored at <icon size>/mimetypes/<mime type>.png), and use one of the many JavaScript libraries to map the file name/extension to a MIME type.