406334 - drawWindow call crashes

Status: RESOLVED FIXED

(Core :: Graphics: Canvas2D, defect, P3)

Description

[Dave Townsend [:mossop]]

Attachment: testcase

The attached testcase crashes with bp-e7c013eb-9f6b-11dc-a7b9-001a4bd43e5c.

The testcase requires privileges so save locally and it will request them on run.

Comment 1

[Dave Townsend [:mossop]]

The crash is because the window (here an iframe's content window) doesn't QI to an nsIPIDOMWindow. Not sure when that would ever happen?

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

do you want this to block?

Comment 3

[Dave Townsend [:mossop]]

I guess yes I would like it to block, at the very least it is causing me problems trying to write testcases for other bugs. Thing is though I haven't managed to reproduce it from chrome script, only when the script is running in a webpage, so maybe something is up with the process elevation.

Comment 4

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: boring fix

nullcheck piwin QI in here, and we avoid this.  drawWindow will fail shortly after, because we check the piwin QI in DrawWindow itself as well.

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Any idea what the underlying bug is here? I'm not really sure how a window can fail to QI to nsPIDOMWindow.

Comment 6

[Dave Townsend [:mossop]]

Why should the drawWindow call fail at all in this case? The page has elevated privileges so I don't understand why it shouldn't be able to use drawWindow, or am I missing something?

Comment 7

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Because of the failure to QI to nsPIDOMWindow.  I don't know why that's happening -- I can certainly look into it, but doing that will be much lower on my todo list.  I mainly wanted to bandaid over this crash (given that we really should have null checked in the first place, since we do it later on anyway).

Comment 8

[Blake Kaplan (:mrbkap) (inactive)]

This is a combination of bug 396851 and an unfiled bug where if you pass a cross-origin XOW-wrapped object into C++, it'll become an XPCWrappedJS instead of throwing an exception (which is desired, the idea is to remove the need to perform security checks in C++ code -- if you have an nsIFoo that originated in JS, the JS code that passed it to you must have had same-origin or similar access).