guischub@ Thanks for the issue.

Request you to provide a sample extension where this issue can be reproduced, which will help in further triaging.

Thanks..

Hi Susan,

I just made an extension, as simple as possible to demonstrate my issue.
Load it into chrome and navigate to this page :

http://schub.fr/tests/canvas.html

On this page there are 2 canvases, the second one is tainted because of cross domain image being loaded.

If you click on the extension icon, it should log the result of toDataURL() called on said canvas. But instead I get an exception :

Uncaught DOMException: Failed to execute 'toDataURL' on 'HTMLCanvasElement': Tainted canvases may not be exported.

Once again, please note I loaded exactly the same extension on Firefox and was able to receive the image bytes, thanks to the <all_urls> permission.

Deleted: toDataURL.zip 918 bytes

toDataURL.zip 918 bytes Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Able to reproduce the issue on Mac 10.13.3, Win-10 and Ubuntu 17.10 using chrome reported version #68.0.3440.75 and latest canary #70.0.3510.0.
This is a non-regression issue as it is observed from M60 old builds. 

Hence, marking it as untriaged to get more inputs from dev team.

Thanks...!!

Hmm... I don't think this is something we'll want to change for content scripts.  We try to keep content script powers as limited as possible, because they are executing so closely to the untrusted page content (both in terms of executing in the same process and in terms of the ability for the page to find ways to "pierce" the v8 context boundary).  Because of those risks, I don't think granting scripts more privilege, and removing the security boundary, is something we'll do.

That said, extension pages (like your background page, an extension tab, or an extension iframe) are different stories.  Since we let them perform authenticated XHRs to any sources they have access to, it seems like that might be an area that we could relax (if it doesn't work already).  Have you tried this code in the context of an extension page?

Hello and thank you for looking into my issue.

Unless I am missing something, what you are proposing cannot be working for me.

My goal is to export data from a canvas located on content page (basically, export any canvas on any webpage as image).

As far as I know, the background page (or extension tab or extension iframe) has no access to elements on the content, so I cannot export anything useful from here.

That's why I was suggesting to add an extra permission specifically for this, so that the end-user knows the risk when installing such an extension.

Ah, I see.  As a workaround, I wonder if you'd be able to use the pageCapture, tabCapture, or tabs.captureVisibleTab APIs.  But, it's certainly quite a bit clunkier.

I'm not against adding an exception for extensions with proper permissions here, but it might not be something we get to in the near future.  Also +fserb@ (one of the owners of canvas) for their thoughts.

Yes, this is what I am considering at the moment. pageCapture and tabCapture are not adapted to what I'm trying to do.

tabs.captureVisibleTab is a possible alternative, but then I will have to play with scrolling and overflow and it becomes quite pain. Add to it the niceties of dealing with <iframes> and you get quite a challenge.

I guess I'll have no choice but to try with this solution for now, but I'll keep an eye open on this issue hoping to see it progress some day.