Re: Steps to creating a browser standard for the moz-icon:// scheme

You've been getting a lot of feedback from Mozilla.  Jonas Sicking,
Robert O'Callahan, and Boris Zbarsky are all leading members of the
Mozilla community.

Adam


2010/2/3 Pierre-Antoine LaFayette <pierre.lafayette@gmail.com>:
> Is there anyone from Mozilla on this mailing list? I'd like to get their
> opinion on these matters.
>
> 2010/2/1 Pierre-Antoine LaFayette <pierre.lafayette@gmail.com>
>>
>> So it seems like there is a general consensus that at least some parts of
>> the icon URI scheme are useful and are worth standardizing. One thing I was
>> confused about was the mention of the File object; I initially believed we
>> were referring to http://www.mozilla.org/js/js-file-object.html, however, if
>> I'm not mistaken, I think people actually mean the FileUpload object.
>> I've summarized the issues discussed thus far:
>>
>> Possible Usage Examples:
>> # Return the platform icon for the given extension
>> icon:.zip?size=16&state=disabled # query form
>> icon:.mp3;16;disabled # short form
>> # Return the platform icon for the specified file URI
>> icon:file:///home/pierre/test.png
>> # Return an icon for a standardized identifier name
>> icon:stock/gtk-go-up?size=menu
>> icon:stock/newtab;32;disabled
>> icon:stock/home;16
>> icon:stock/refresh;48
>> Security risks
>>   - Probing???
>>     - Mozilla has been exposing the moz-icon scheme to the web for years.
>>   - Avoiding Cross-domain theft of arbitrary images; machine
>> fingerprinting
>>     - Canvas getPixelData and toDataURL API calls
>>       - The only issue has been the cross-domain image theft
>> (http://scarybeastsecurity.blogspot.com/2008/11/firefox-cross-domain-image-theft-and.html)
>> vulnerability in Firefox 2 that has since been resolved with cross-domain
>> checks.
>>     - User interaction visual exploit
>>       - Gets user to confirm a known pixel is present in the icon image
>>       - Very loose "exploit"; basically tricking a user into providing
>> information about her installed applications
>>       - Mozilla allows this "exploit"
>>   - Can retrieve the width and height of an image without security checks.
>> File URIs in icon scheme
>>   - What are the use cases?
>>     - Browser, local html, web sites where files are uploaded by user.
>>   - Risk of file system probing??
>>     - Maybe if somehow the web site can acess the image data for an icon.
>>   - Can we use an input File object instead?
>>     - Idea: Get a magic restricted-use URL for that file's icon from the
>> File object, the same as you can get a URL for the file's contents.
>>     - Idea: The File object could give you an icon: URL that specifically
>> identifies that file's icon.
>>     - Idea: The File object could give you the data URI for the icon.
>>
>> Stock Images
>>   - Should we include the "stock" image option in the specification?
>>     - Hard to define a common set of icons (and sizes) across all
>> platforms
>>     - Cross platform: save, zoom in/out, print, folder, file, cut, paste,
>> copy, delete, add, ok, cancel, about, info, help, quit, strikethrough,
>> underline, select font, select color, quote, center, left/right align,
>> change font, text-size, list, bold, italic, etc.
>>     - E.g. http://www.pygtk.org/docs/pygtk/gtk-stock-items.html
>>     - Browser specific: newtab, forward, back, stop, home, refresh, etc.
>>     - Possibly find a set of creative common icons that can always be used
>> if the platform does not provide the stock icons.
>>     - How do we choose which icons should be included in the stock?
>>
>> Icon Sizes
>>   - Default image size of 16x16
>>   - Should sizes be predefined identifiers, e.g. tiny, small, medium,
>> large?
>>   - What sizes are acceptable?
>>       - Platform differences
>>         - Mac OSX supports: 16×16, 32×32, 48×48, 128×128, 256×256 and
>> 512×512 pixels and multiple states
>>         - Windows XP supports: 16x16, 32x32, 48x48 and upscales up to
>> 256x256
>>     - Should an arbitrary integer be allowed causing a potential scaling
>> of icons?
>> Naming of URI
>>   - Should we use about:icon or res:icon rather than add a new scheme?
>>   - IMO, icon: is still the ideal choice.
>>
>> The two big ones are: the allowance of the file:// syntax versus adding a
>> getIconURI() type method to the FileUpload object and the support for stock
>> images.
>> Perhaps the file:// syntax can work for internal and local pages in the
>> same way that the file URI only works locally. Whereas the FileUpload object
>> can be used to retrieve the icon URI or data URI or something. I'm guessing
>> the icon URI returned would have to be using the icon:<file-extension>
>> syntax?
>> For the stock images, if people could comment on the plausibility of this
>> option.
>> 2010/2/1 Ian Fette (イアンフェッティ) <ifette@google.com>
>>>
>>> Just to be clear, I believe Pierre was referring to file extensions (e.g.
>>> ".jpg") not browser extensions.
>>> At any rate, I think it would be convenient, if you are able to get a
>>> File handle, to also be able to get an image representation of the file.
>>> That could be some thumbnail if the OS has already generated and stored a
>>> thumbnail and it's essentially free to get it on the platform, or if a
>>> thumbnail is not available (or perhaps regardless of whether or not a
>>> thumbnail is available) you could get some other image representation that
>>> is somehow representative of the file type (e.g. some icon for JPEG files --
>>> this image does not need to be part of the standard, does not need to be
>>> consistent across browsers, but should ideally be consistent for all JPEG
>>> files you call "geticon" on within the same UA on the same computer...
>>> My $0.02
>>>
>>> 2010/1/31 Maciej Stachowiak <mjs@apple.com>
>>>>
>>>> On Jan 29, 2010, at 10:29 AM, Pierre-Antoine LaFayette wrote:
>>>>
>>>>
>>>> 2010/1/29 Ian Fette (イアンフェッティ) <ifette@google.com>
>>>>>
>>>>> 2010/1/28 Maciej Stachowiak <mjs@apple.com>
>>>>>>
>>>>>> On Jan 28, 2010, at 8:39 PM, Ian Fette (イアンフェッティ) wrote:
>>>>>>
>>>>>> It's interesting to note that on most modern OSes (Mac OS X, Vista,
>>>>>> Win 7 ...) the OS actually does create a pre-computed high quality icon for
>>>>>> many files, e.g. images, PDF, Word, Photoshop, .... It is almost free to get
>>>>>> this from the OS, and the OS also has 3 default sizes for it. It would be
>>>>>> great to provide access to this if you have a File handle to it.
>>>>>>
>>>>>> Mac OS X has 5 default sizes and can reasonably efficiently
>>>>>> interpolate sizes in between. On the other hand, iPhone OS doesn't have any
>>>>>> file icons, or even a really user-visible concept of files. So I'm not sure
>>>>>> we can make too many assumptions about what will hold across platforms.
>>>>>> Regards,
>>>>>> Maciej
>>>>>
>>>>> Sure - there are some platforms where it may not be available
>>>>> (including perhaps winxp?). But it's an interesting idea to expose these if
>>>>> they are available, and if they're not available, then fall back to some
>>>>> default.
>>>>
>>>> Perhaps if we found some creative commons icons to use as defaults for
>>>> the most used extensions. It wouldn't match the native theme but at least
>>>> we'd have something for cases where platform icons are not available. We'd
>>>> need to have some number of sizes. I think Windows goes to a max of 72x72,
>>>> while Mac OSX goes to 128x128. Mozilla defines the size as:
>>>>
>>>>    *   Parameter:   size
>>>>    *   Values:      [<integer> | button | toolbar | toolbarsmall | menu
>>>> | dialog]
>>>>    *   Description: If integer, this is the desired size in square
>>>> pixels of the icon
>>>>    *                Else, use the OS default for the specified keyword
>>>> context.
>>>>
>>>>
>>>> <integer> scales the icons to the desired size. I think we'd at least
>>>> need a few different sizes for a default set of icons. I'm not sure that
>>>> such icons exist.
>>>>
>>>> I don't see a need to standardize anything solely for use by extensions.
>>>> What we should ask is which icons are useful for Web content, since that is
>>>> where we have the interoperability constraint. Extensions do not currently
>>>> interoperate between different browsers, nor is this planned as far as I can
>>>> tell, so they cannot be the sole use case for any part of a Web standard
>>>> IMO.
>>>> Regards,
>>>> Maciej
>>>
>>
>>
>>
>> --
>> Pierre.
>
>
>
> --
> Pierre.
>

Received on Wednesday, 3 February 2010 19:26:27 UTC