Re: devtools highlighter
Patrick Brosset <[email protected]>
| Newsgroups | gmane.comp.mozilla.devel.layout |
|---|---|
| Message-ID | <[email protected]> |
On 3/23/14, 10:22 PM, Ehsan Akhgari wrote: > On 2014-03-23, 6:07 AM, Robert O'Callahan wrote: >> On Fri, Mar 21, 2014 at 9:55 PM, Patrick Brosset >> <[email protected]>wrote: >> >>> We're struggling with a limitation related to the devtools highlighter >>> (the outline you see in this video: >>> https://www.youtube.com/watch?v=zBYEg40ByCM). >>> Today, the highlighter is created with XUL nodes that are appended >>> in the >>> browser XUL markup, in one of the parent elements of the page currently >>> being inspected. These XUL nodes are absolutely positioned over the >>> element >>> being highlighted. >>> >>> This technique has served us well until we wanted our devtools to >>> work on >>> Fennec, Fxos and E10S mode. In these cases, the page being inspected >>> doesn't have a reachable parent element that we can use to append our >>> highlighter elements, and appending it inside the content page >>> itself isn't >>> really a viable option because we don't want to impact the content >>> in any >>> way. >>> >> >> I think you need an API to add anonymous content to the root element >> of the >> page. We don't have such an API at the moment but it might not be >> hard to >> add. > > Bug 924692 is making the canvas frame have a native anonymous content. > If that is where you would like to stick that element in, then art of > the frame constructions bits is being done in that bug. > > Cheers, > Ehsan Thanks Rob and Ehsan for that information. I believe being able to add anonymous content to the root element of the page is what we need indeed. This way we can keep on using HTML and CSS to display our highlighter (or whatever we want to overlay on content from the devtools in the future), which is what we're comfortable with. To be honnest I'm not familiar with what the root canvas frame is (relatively new to firefox development), but I'm guessing the way to proceed now is waiting for bug 924692 to land, and filing a new one to have this anonymous content API accessible to chrome privileged js code. Cheers, Patrick