678663 - Personas cannot be previewed from moz-filedata uris

Status: RESOLVED INACTIVE

(Toolkit :: Add-ons Manager, defect)

Description

[Christopher Van Wiemeersch [:cvan]]

A Persona cannot be previewed when `moz-filedata` is passed as a preview image URL (i.e., `headerURL`, `footerURL`).

Comment 1

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

I don't really understand how Personas work.  Can you put a testcase up somewhere that I can play with?

Comment 2

[Christopher Van Wiemeersch [:cvan]]

http://people.mozilla.org/~cwiemeersch/personas.html

I've created a test case wherein you can see (1) a Persona being referenced by an HTTP URL and (2) upload an image to reference the Persona by a moz-filedata URI.

Please let me know if you have any questions. Thanks!

Comment 3

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Thanks for the testcase.

Personas has a protocol whitelist at http://hg.mozilla.org/mozilla-central/annotate/922f27baed98/toolkit/mozapps/extensions/LightweightThemeManager.jsm#l647 that does not include moz-filedata.

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+2]]

How close is that to bug 577606?

Comment 5

[Boris Zbarsky [:bzbarsky]]

Very close.  Why exactly are we, once again, using some sort of hardcoded protocol list?  :(

Comment 6

[Christopher Van Wiemeersch [:cvan]]

Hey, just checking in. Any update on this?

Comment 7

[Matthew N. [:MattN]]

Attachment: WIP allow data, blob & moz-filedata URIs for lightweight themes

Dão, is there more to this than just adding these schemes to the whitelist?

In terms of security we already require the site to be on the add-on whitelist in order to preview and we show a notification bar in order to install.

If this approach is fine I'll write tests for it.

AMO would like to use this to allow authors to preview personas before they are uploaded to the site.

Comment 8

[Dão Gottwald [:dao]]

Comment on attachment 571897 [details] [diff] [review]
WIP allow data, blob & moz-filedata URIs for lightweight themes

I don't know what the blob protocol is, but in general this is the right place.

You should probably update _persistImage, as persisting won't be needed e.g. for "data"?

Comment 9

[Mike Kaply [:mkaply]]

The line Dao is talking about is here:

http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/LightweightThemeManager.jsm#774

That protocols list should be moved out of sanitizeTheme so it can be used in both places.

Comment 10

[Matthew N. [:MattN]]

Comment on attachment 571897 [details] [diff] [review]
WIP allow data, blob & moz-filedata URIs for lightweight themes

(In reply to Dão Gottwald [:dao] from comment #8)
> Comment on attachment 571897 [details] [diff] [review]
> WIP allow data, blob & moz-filedata URIs for lightweight themes
> 
> I don't know what the blob protocol is, but in general this is the right
> place.

The blob protocol is the standardized version of moz-filedata.

I've attached a patch on bug 678663 for data URIs which could be used as a workaround for lack of moz-filedata once that bug is resolved. I think that adding data URI support will reduce most of the need for moz-filedata support since the result as a persona would be the same.

It may make sense for previewing but it doesn't for installing since it's revoked when the documented that created it is unloaded [1].  That would mean either:
a) supporting moz-filedata for preview only - this may be confusing to users and developers
b) Converting personas with moz-filedata URLs to data ones so that they will persist. This can be done just as easily by a web developer once bug 678663 is fixed.

[1] http://dev.w3.org/2006/webapi/FileAPI/#lifeTime

Comment 11

[Christopher Van Wiemeersch [:cvan]]

(In reply to Matthew N. [:MattN] from comment #10)
> b) Converting personas with moz-filedata URLs to data ones so that they will
> persist. This can be done just as easily by a web developer once bug 678663
> is fixed.

Do you mean bug 577606?

Comment 12

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.