Patrick Brosset <:pbro> Reporter
	Description • 10 years ago

This chrome-only API was added in bug 1020244.
Most of the implementation resides in nsCanvasFrame.cpp, which is where inserted elements are appended.

However, XUL windows do not have a canvas frame.

According to bug 1020244 comment 38, the closest thing for XUL windows is nsRootBoxFrame.

This API is now used by the devtools highlighter, so it means the highlighter doesn't work for elements in XUL windows.

	Boris Zbarsky [:bzbarsky]
	Comment 1 • 10 years ago

Why is the impl in nsCanvasFrame, not nsViewportFrame?

	Patrick Brosset <:pbro> Reporter
	Comment 2 • 10 years ago

(In reply to Boris Zbarsky [:bz] from comment #1)
> Why is the impl in nsCanvasFrame, not nsViewportFrame?
Other than that's what was discussed here https://groups.google.com/forum/#!topic/mozilla.dev.tech.layout/fiWpoAGnc8Q I don't know that there's a technical reason for having it in nsCanvasFrame rather than nsViewportFrame.
Is nsViewportFrame a parent of nsCanvasFrame? Does it also exists in case of XUL windows? If yes, then it looks like the right candidate to move the API to and therefore have the whole thing work for XUL windows too.

	Boris Zbarsky [:bzbarsky]
	Comment 3 • 10 years ago

> Is nsViewportFrame a parent of nsCanvasFrame?

Yes.  See the big comment in nsCSSFrameConstructor::SetUpDocElementContainingBlock for how the frames around the root element look in various cases.

> Does it also exists in case of XUL windows?

Yes.

One major difference is what happens when scrolling: the viewport frame doesn't move, but the canvas frame does.  I'm not sure whether that affects your use case or not....

	Patrick Brosset <:pbro> Reporter
	Comment 4 • 10 years ago

(In reply to Boris Zbarsky [:bz] from comment #3)
> > Is nsViewportFrame a parent of nsCanvasFrame?
> 
> Yes.  See the big comment in
> nsCSSFrameConstructor::SetUpDocElementContainingBlock for how the frames
> around the root element look in various cases.
Nice, thanks.
> > Does it also exists in case of XUL windows?
> 
> Yes.
> 
> One major difference is what happens when scrolling: the viewport frame
> doesn't move, but the canvas frame does.  I'm not sure whether that affects
> your use case or not....
I don't think this should affect the use case at all. The new native anonymous element that I added to the canvas frame is supposed to not scroll. It is styled with 'position: fixed;' in ua.css.
So if I'm getting this correctly, we should be able to move the code from nsCanvasFrame to nsViewportFrame, and "just" remove the fixed positioning, and it should more or less be transparent. Too optimistic? Or is this correct?

	Boris Zbarsky [:bzbarsky]
	Comment 5 • 10 years ago

Possibly a bit optimistic, because the viewport frame assumes things about its child frame list, so it'll take a bit of work both in that class and possibly in the frame constructor to get things set up right.  But yes, that's the general idea.  Or at least worth trying.

The other option is to copy the code that's in nsCanvasFrame to nsRootBoxFrame, I guess, and hope it doesn't confuse the XUL box model too much.

	BMO Automation
	Comment 7 • 6 years ago

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.