Open
Bug 1094959
Opened 10 years ago
Updated 2 years ago
Support document.insertAnonymousContent in XUL documents
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
REOPENED
People
(Reporter: pbro, Unassigned)
References
(Blocks 1 open bug)
Details
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.
Comment 1•10 years ago
|
||
Why is the impl in nsCanvasFrame, not nsViewportFrame?
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.
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....
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?
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.
Updated•8 years ago
|
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.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INACTIVE
Updated•6 years ago
|
Status: RESOLVED → REOPENED
Resolution: INACTIVE → ---
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•