1.47 KB, application/zip
46 bytes, text/x-phabricator-request
|Details | Review|
13.29 KB, patch
|Details | Diff | Splinter Review|
109.43 KB, image/png
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
status-firefox61: --- → affected
status-firefox62: --- → affected
status-firefox63: --- → affected
Component: Untriaged → Frontend
Ever confirmed: true
Product: Firefox → WebExtensions
Is this easier to do since bug 1310318?
> 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
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
Please land this patch instead of using Lando (see bug 1486026).
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/3039bfc0e270 Add selective canvas tainting for content scripts r=bzbarsky
Status: ASSIGNED → RESOLVED
Last Resolved: 6 months ago
status-firefox64: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla64
status-firefox61: affected → wontfix
status-firefox62: affected → wontfix
status-firefox63: affected → wontfix
QA Contact: ddurst
QA Contact: ddurst
You need to log in before you can comment on or make changes to this bug.