Closed Bug 1484980 Opened 2 years ago Closed 2 years ago

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

Categories

(WebExtensions :: Frontend, defect, P3)

63 Branch
defect

Tracking

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

VERIFIED FIXED
mozilla64
Tracking Status
firefox-esr60 67+ fixed
firefox61 --- wontfix
firefox62 --- wontfix
firefox63 --- wontfix
firefox64 --- verified

People

(Reporter: ngyikp, Assigned: zombie)

Details

Attachments

(4 files, 1 obsolete file)

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: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla64
Attachment #9012367 - Attachment is obsolete: false
Attached 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
You need to log in before you can comment on or make changes to this bug.