Closed Bug 296311 Opened 19 years ago Closed 19 years ago

Cannot use drawWindow method on canvas on local page with enablePrivilege code

Categories

(Core :: Graphics: Canvas2D, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

VERIFIED FIXED

People

(Reporter: martijn.martijn, Assigned: vlad)

References

()

Details

(Keywords: testcase)

Attachments

(2 files)

I tried to use the new drawWindow method on the canvas.
See testcase.
That testcase uses enablePrivilege, so you have to test it locally on the
computer to test if it works. Currently it does not, but I think it should work
at least with one form of the enablePrivilege code.

This is what Boris said about it on IRC:
	bz	{#developers} mw22: the relevant code in
nsCanvasRenderingContext2D::DrawWindow is:
	bz	1767 PRBool isChrome = PR_FALSE;
	bz	1768 ssm->SubjectPrincipalIsSystem(&isChrome);
	bz	1769 if (!isChrome)
	bz	1770 return NS_ERROR_FAILURE;
	bz	{#developers} mw22: well. we need the security check in some form.
	bz	{#developers} mw22: probably IsCapabilityEnabled("UniversalBrowserRead") is
what we want to be checking
	bz	{#developers} mw22: I think UniversalBrowserRead is a reasonable thing to
check there; of you have it, you can get the data anyway
Attached file testcase
To be sure, I attach the url testcase here. 
It might be that the testcase needs adjusting (which enablePrivilege to use),
depending on how this bug gets fixed.
Summary: Cannont use drawWindow method on canvas on local page with enablePrivilege code → Cannot use drawWindow method on canvas on local page with enablePrivilege code
Add check for UniversalBrowserRead or UniversalXPConnect privs; also fixes a
call to cairo_set_source_surface that's making DrawWindow unusable on the trunk
(bug 296697).
Assignee: nobody → vladimir
Status: NEW → ASSIGNED
Attachment #185441 - Flags: review?(shaver)
Comment on attachment 185441 [details] [diff] [review]
drawwindow-perms.patch

Change the 3 if's to use || and r=pavlov
Attachment #185441 - Flags: review?(shaver) → review+
Comment on attachment 185441 [details] [diff] [review]
drawwindow-perms.patch

So why do we have !isTrusted in the RenderOffscreen call, if isTrusted can only
be true if we get there?

Also, I'd rather see an explicit

if (!isTrusted)
    return NS_ERROR_DOM_SECURITY_ERR;

Relying on the else-chaining seems fragile; it'd be easy to add another chunk
in there and not realize that it was a security-grant even if you don't set
isTrusted.
Comment on attachment 185441 [details] [diff] [review]
drawwindow-perms.patch

a=shaver with changes from IRC.
Attachment #185441 - Flags: approval1.8b3? → approval1.8b3+
in with fixes, thanks
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
The reason for the isTrusted thing is so we can add untrusted rendering later
without changing the API.
It works, it works!!! Thank you! :-)
Status: RESOLVED → VERIFIED
Flags: in-testsuite?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: