If you have an element in the page with > position: fixed; > z-index: 2147483647; the highlighting lines and area would be covered by this element. Test page: data:text/html,<div style="margin:50px;padding:50px;position:fixed;z-index:2147483647;background:pink;width:50px;height:50px;"> In the page above, lines are never shown inside the pink block. It makes it impossible to inspect elements when the document is in fullscreen (via the Fullscreen API, not the browser full screen mode). With bug 1126230, we implement the top layer concept for the Fullscreen API, which makes the fullscreen element be painted in an even higher place than fixed-position elements with maximum z-index. The element highlighting should work with fullscreen elements.

We are using the canvasframe container for appending highlighters, I'm not sure if there is a way to get this above this top layer. Is there any documentation about using this top layer thing? Maybe it's something we could migrate the highlighters to - although they are relying on the DOM-like properties of the canvas frame so we can render SVG outside of the page DOM across platforms.

The top layer is currently only implemented for Fullscreen API, which is currently the only entry for using it. We may use this for <dialog> as well in the future, though. (Although we use -moz-top-layer property for putting elements in the top layer, non-fullscreen element with this property would simply not be rendered at all, because we need to render the frames in a specific order according to a list in DOM) The top layer is rendered on the topmost in the viewport frame, which I guess currently nothing can be rendered on top of it in a document. So we may need to add some mechanism for devtools to do that. Could you show me how the highlighters work currently in code? That may help for figuring out what we can do in the layout side.

The devtools highlighters generate HTML content that is injected into a native anonymous node in the CanvasFrame frame. The way devtools injects this content is by using the chrome only document's InsertAnonymousContent function: https://dxr.mozilla.org/mozilla-central/source/dom/base/nsDocument.cpp#5294 This clones and appends the content into a canvasframe's native anon node: https://dxr.mozilla.org/mozilla-central/source/layout/generic/nsCanvasFrame.h#103 Which happens to be styles in ua.css: https://dxr.mozilla.org/mozilla-central/source/layout/style/ua.css#513 with: position: fixed; and z-index: 2147483648; The way devtools then accesses content to manipulate it is via the AnonymousContent webidl: https://dxr.mozilla.org/mozilla-central/source/dom/webidl/AnonymousContent.webidl (this provides a sort of restricted API that avoids chrome JS code from directly accessing the DOM in the native anonymous node). On the JS side, in devtools, we've created a helper to inject and manipulate content: https://dxr.mozilla.org/mozilla-central/source/devtools/server/actors/highlighters/utils/markup.js#173

(In reply to Patrick Brosset [:pbrosset] [:pbro] from comment #3) > Which happens to be styles in ua.css: > https://dxr.mozilla.org/mozilla-central/source/layout/style/ua.css#513 > with: position: fixed; and z-index: 2147483648; 2147483648 wouldn't work, it would just be clamped to 2147483647. OK, so it seems we always want the anonymous content to be rendered on the topmost. I guess we can simply switch to render it after the top layer phase in the layout code, and then no change is needed from the devtools side.

Bug 1215360 - Render canvas anonymous content on top of the top layer.

Comment on attachment 8675466 [details] MozReview Request: Bug 1215360 - Render canvas anonymous content on top of the top layer. https://reviewboard.mozilla.org/r/22365/#review19967

https://hg.mozilla.org/integration/mozilla-inbound/rev/9a87c1e0edec666c50f8ba09923840b3b2ddc6cf Bug 1215360 - Render canvas anonymous content on top of the top layer. r=roc

Awesome Xidorn, thanks for finding this solution!