Canvas toDataURL doesn't work with loaded images on WebExtensions content scripts

VERIFIED FIXED in Firefox -esr60

Status

defect
P3
normal
VERIFIED FIXED
11 months ago
2 months ago

People

(Reporter: ngyikp, Assigned: zombie)

Tracking

63 Branch
mozilla64
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox-esr6067+ fixed, firefox61 wontfix, firefox62 wontfix, firefox63 wontfix, firefox64 verified)

Details

Attachments

(4 attachments, 1 obsolete attachment)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3521.2 Safari/537.36

Steps to reproduce:

My WebExtension has an image resizer functionality using FileReader and canvas API, but I can't implement it on Firefox due to some SecurityError, it even fails with a hardcoded image on the content script's source code.

Seems that someone has been having this issue for a very long time: https://stackoverflow.com/questions/41042660/firefox-web-extension-todataurl-operation-is-insecure

1. Install the attached WebExtension
2. Go to http://example.com on both Chrome and Firefox


Actual results:

On Firefox, the `canvas.toDataURL` refuses to work with the error: "SecurityError: The operation is insecure"

My user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:63.0) Gecko/20100101 Firefox/63.0


Expected results:

It works fine on Chrome
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0 (20180824100112)

I have tested this report using latest Nightly and Firefox release channels. I was able to reproduce the mentioned behavior on Windows 10 x64 and OS X 10.12 using the above steps. When loading the provided add-on and navigating to http://example.com, I'm seeing "SecurityError: The operation is insecure" error.
Status: UNCONFIRMED → NEW
Component: Untriaged → Frontend
Ever confirmed: true
Product: Firefox → WebExtensions
Priority: -- → P3
Is this easier to do since bug 1310318?
Flags: needinfo?(tomica)
> Is this easier to do since bug 1310318?

It's a bit different, the canvas could be dirty from a domain that even the extension doesn't have permission for, so I think we'll need alternative dirty flag bookkeeping specifically for extensions.

I'll investigate next week.
Assignee: nobody → tomica
Status: NEW → ASSIGNED
Flags: needinfo?(tomica)
So, turns out a content script drawing its own data: URI image to a canvas marks it writeOnly.  This is because the canvas is part of the content document, and its principal doesn't subsume the extension content script principal.

Which all makes sense, except when the canvas was also created by that same content script, which is now unable to read from it.

I think we can work around this by noting when a canvas is (only) tainted by resources from an addon principal, keeping track of it and letting callers with that same principal read from the canvas later.

The canvas should still behave as writeOnly from web content's perspective, but be accessible to the content script.
Comment on attachment 9012367 [details]
Bug 1484980 - Add selective canvas tainting for content scripts r?bzbarsky

Boris Zbarsky [:bzbarsky, bz on IRC] has approved the revision.
Attachment #9012367 - Flags: review+
Attachment #9012367 - Attachment description: Bug 1484980 - Add selective canvas tainting for content scripts r?kmag → Bug 1484980 - Add selective canvas tainting for content scripts r?bzbarsky
Attachment #9012367 - Attachment is obsolete: false
Please land this patch instead of using Lando (see bug 1486026).
Attachment #9012367 - Attachment is obsolete: true
Attachment #9013096 - Attachment is obsolete: true
Attachment #9013096 - Flags: checkin?
Attachment #9013105 - Flags: review+
Attachment #9013105 - Flags: checkin?
Pushed by btara@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/3039bfc0e270
Add selective canvas tainting for content scripts r=bzbarsky
Attachment #9013105 - Flags: checkin?
https://hg.mozilla.org/mozilla-central/rev/3039bfc0e270
Status: ASSIGNED → RESOLVED
Closed: 10 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla64
Attachment #9012367 - Attachment is obsolete: false
Posted image Bug1484980.png
I was able to reproduce this issue on Firefox 62.0.2(20180920131237) under Win 7 64-bit and  Mac OS X 10.13.3.

This issue is verified as fixed on Firefox 64.0a1(20181001220118) under Win 7 64-bit and Mac OS X 10.13.3.

Please see the attached screenshot.
Status: RESOLVED → VERIFIED
QA Contact: ddurst

Adding this to patches needed for bug 1502799.

You need to log in before you can comment on or make changes to this bug.