1157592 - Anonymous content API doesn't work for SVG documents

Status: RESOLVED FIXED

(DevTools :: Inspector, defect, P3)

Description

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Anonymous content API doesn't work if used for SVG documents


STR1:
There are not highlighters displayed for SVG documents

1) Load https://bug1121432.bugzilla.mozilla.org/attachment.cgi?id=8548868#arrows
2) Open devtools Toolbox (F12)
3) Select the Inspector panel 
4) Hover over elements in the panel, there are no highlighter in the content -> BUG


STR2:
Anonymous content API can be used by extensions too

1) Install PixelPerfect extension (it's also using anon content) https://github.com/firebug/pixel-perfect/wiki
2) Load https://bug1121432.bugzilla.mozilla.org/attachment.cgi?id=8548868#arrows
3) Create layer, it's not visible in the SVG document -> BUG


Honza

Comment 1

[Patrick Brosset <:pbro>]

Thanks for filing. I had stumbled on this problem a while back and thought I had filed a bug, but apparently didn't since I can't find it.

Displaying the highlighter on SVG nodes inside an HTML document works fine. But the highlighter isn't visible on SVG documents.
There's no errors or crashes, so the highlighter content gets inserted in the native anonymous content fine. Only, it's not visible.

Ehsan, is there a difference between the canvasFrame in a SVG document and a HTML document that would make the content inserted via [1] not show up?

[1] http://mxr.mozilla.org/mozilla-central/source/dom/webidl/Document.webidl#382

Comment 2

[Boris Zbarsky [:bzbarsky]]

> is there a difference between the canvasFrame in a SVG document and a HTML document

The canvasFrame is fine.

The difference between SVG and HTML is that when we try to show the custom content container after appending kids to it we treat that as an insertion of the custom content container under the document root element.  And per spec, non-SVG kids of SVG elements (with the exception of kids of <svg:foreignObject>) do not get rendered.  So it's not rendered.

Comment 3

[Patrick Brosset <:pbro>]

(In reply to Not doing reviews right now from comment #2)
> > is there a difference between the canvasFrame in a SVG document and a HTML document
> 
> The canvasFrame is fine.
> 
> The difference between SVG and HTML is that when we try to show the custom
> content container after appending kids to it we treat that as an insertion
> of the custom content container under the document root element.  And per
> spec, non-SVG kids of SVG elements (with the exception of kids of
> <svg:foreignObject>) do not get rendered.  So it's not rendered.
Thanks bz. That makes a lot of sense of course now that you've explained :) (clearing NI? flag for Ehsan).

We have a couple of options here I guess:
- wrap the highlighter into a foreignObject
- come up with a different highlighter for SVG documents
- make our highlighter fully SVG. It's already something like 90% SVG right now
This will need some experimenting first.

Comment 4

[Boris Zbarsky [:bzbarsky]]

And incidentally, it's a bit weird that we construct the frame differently depending on whether we already have anonymous content when we're constructing the canvas or not.  If we already have anonymous content when we construct the canvas, then we put the placeholder for the anon div as a child of the CanvasFrame directly.  But if we add the anon content after the canvas has been constructed already, the placeholder ends up as a child of the document element's frame, because we take the normal content-insertion codepath.  Which, by the way, warns about this being broken:

  WARNING: Someone passed native anonymous content directly into frame construction. 
  Stop doing that!: file ../../../mozilla/layout/base/nsCSSFrameConstructor.cpp,
  line 6551

Basically, the dynamic showing/hiding of the anonymous container is broken: it fails in SVG because of the check I describe in comment 2, and if that check were adjusted to allow it it would _still_ fail because it would try to put a placeholder into an SVG frame....  What should really be happening here is that we should be going through the same codepath that nsCSSFrameConstructor::ConstructAnonymousContentForCanvas would go through, when we try to show the anonymous content container.

Comment 5

[Boris Zbarsky [:bzbarsky]]

>- wrap the highlighter into a foreignObject

You mean make the anon content container in CanvasFrame a foreignObject?

> make our highlighter fully SVG.

That won't help, since it's the anon content container that's a <div>.

Comment 6

[Patrick Brosset <:pbro>]

(In reply to Not doing reviews right now from comment #5)
> >- wrap the highlighter into a foreignObject
> 
> You mean make the anon content container in CanvasFrame a foreignObject?
No I meant wrap our own highlighter content in a foreignObject but, you're right, I forgot the anon content container was a div, so that wouldn't work.
Maybe we could make it a foreignObject if we know the document is SVG, a div otherwise.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Needs to be based on the root element, not on the document type.  And @hidden doesn't work on <foreignObject>...

Comment 8

[Julian Descottes [:jdescottes]]

Inspector bug triage. Filter on CLIMBING SHOES

Comment 12

[Mike de Boer [:mikedeboer]]

This new findbar highlighter is also hitting this bug (see bug 1302969). Boris, is there someone available who might be available to implement your suggestion from comment 4?
Brad Werth has implemented a few platform additions for the findbar highlighter specifically, which has been been tremendously helpful (and awesome). Perhaps this is something interesting for him to tackle?
Note: it'll make the devtools team happy as well ;-)

Comment 13

[Brad Werth [:bradwerth]]

I'll take this on. Boris, I'm happy to hear any additional implemenation guidance.

Comment 14

[Boris Zbarsky [:bzbarsky]]

I'm not sure I have anything else, offhand.  Basically, we want to detect the "showing the anonymous content thing" case and not do normal frame construction, doing something more like ConstructAnonymousContentForCanvas instead.

Comment 15

[Brad Werth [:bradwerth]]

Okay, from debugging this, it seems that both types of content (HTML and SVG) get a created canvas frame. The difference I can find appears to be in the JS invocation. In the HTML case, I believe that JS applies new styles to the elements (or perhaps creates new elements that use a code path that looks like restyling). In the SVG case, there's no JS invocation that leads to restyle. To me, this indicates that there's a conditional in the JS that decides whether or where to apply the new styles (or add the new elements). I would really like to see the JS that does the restyling and/or the addition of content frames, and this will help me guide the SVG case into the proper code path.

And in the spirit of improving myself, if there's a way to correlate a Gecko stacktrace back to the JS source, I would love to learn how to do it.

Comment 16

[Boris Zbarsky [:bzbarsky]]

> if there's a way to correlate a Gecko stacktrace back to the JS source

Calling the DumpJSStack() function is the simplest way to do it, as long as you're on mainthread.  See http://searchfox.org/mozilla-central/rev/02a56df6474a97cf84d94bbcfaa126979970905d/js/xpconnect/src/nsXPConnect.cpp#1202-1237 (which includes some other maybe-useful debugger helpers).  There are some edge cases where this won't do the right thing, but if you're actually under a call from JS it should work properly.

Comment 17

[Mike de Boer [:mikedeboer]]

Brad, I've just printf-debugged the entire JS stack for the findbar on this SVG document: https://bug1294843.bmoattachments.org/attachment.cgi?id=8780694.
See the important bits highlighted here: https://searchfox.org/mozilla-central/source/toolkit/modules/FinderHighlighter.jsm#991,1113,1152

The first two are for the dimmed background and cutting out the rects, the third is about the yellow box for the current match.

I've watched these methods being invoked, but don't do anything yet. So I'm saying: there must be a conditional in the C++ that short-circuits things before it moves to layout in SVG documents.

Comment 18

[Brad Werth [:bradwerth]]

Attachment: Malformed tooltip in SVG

This is what happens when the anonymous content container is never hidden in an SVG document. The anonymous content div is a child of the nsDocument, and its contents get rendered like so.

Comment 19

[Brad Werth [:bradwerth]]

(In reply to Boris Zbarsky [:bz] (still a bit busy) from comment #4)

> Basically, the dynamic showing/hiding of the anonymous container is broken:
> it fails in SVG because of the check I describe in comment 2, and if that
> check were adjusted to allow it it would _still_ fail because it would try
> to put a placeholder into an SVG frame....  What should really be happening
> here is that we should be going through the same codepath that
> nsCSSFrameConstructor::ConstructAnonymousContentForCanvas would go through,
> when we try to show the anonymous content container.

It looks to me like both HTML and SVG documents get their anonymous content containers using the same mechanism (through nsCSSFrameConstructor::ConstructAnonymousContentForCanvas), and the div element in each case is attached as a child of the document. The show / hide behavior sets a "hidden" attribute, which causes the anonymous content container to be taken out of layout when hidden and then reflowed back into layout when shown. It is in the reflow layout where evidentally the container is moved to a different location in the hierarchy or otherwise removed -- I haven't investigated that code path yet.

Anyway, I wanted to see if the container worked if it was just left alone and never hidden/shown (and therefore never reflowed). Attachment 8831324 [details] shows the result: the tooltips render irregularly for the SVG document. They still appear fine in HTML documents. After reading comment 3, I assume that the SVG elements of the tooltip are rendering correctly and the HTML elements are not.

So I think there are some smaller steps to solving this:

1) Find the step in reflow where the anonymous content container is treated differently in SVG vs HTML documents, and change it to make both paths put the container back as a child of the document. Boris, if you know where this is, I'd love to know.

2) Modify the highlighter so it is all SVG, as proposed by Patrick in comment 3. It seems that when we get this thing visible and parented, any HTML elements in it will not render per spec as mentioned in comment 2.

Comment 20

[Boris Zbarsky [:bzbarsky]]

> Boris, if you know where this is, I'd love to know.

This is what comment 2 was about.  It's not happening during reflow; it's happening during frame construction.  In both the HTML and SVG case we screw things up and put the frame in the wrong place (as a child of the document element's frame, not as a child of the canvas frame).  The difference is that for HTML it's OK to have a random kid of the <html> element and have it render, while for SVG it's not OK to have a non-SVG child of the root <svg>: the SVG spec says it shouldn't be rendered, so we don't render it.  That check happens in  nsCSSFrameConstructor::AddFrameConstructionItemsInternal; search for the "Don't create frames for non-SVG element children of SVG elements" comment.

What needs to happen to fix this part is what I said in comment 14, so we parent the anon content frames correctly.

None of that explains the problem when you never hide the anon content, at first glance.  It's really not clear to me why, without further debugging, why that's happening.

One experiment that is worth doing is what happens if you never hide the tooltips, load an SVG document, then replace all the document's kids (i.e. including the root <svg>) with some sort of HTML-namespaced DOM that you can then inspect.  Or vice versa: load an HTML document, then replace the DOM with SVG elements only.  That will at least tell you whether the issue has to do with the type of root element or something about the document itself...

Comment 21

[Brad Werth [:bradwerth]]

Attachment: Bug 1157592 Part 1: Refactor out a helper function to add frames for anonymous content items.

Review commit: https://reviewboard.mozilla.org/r/108362/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/108362/

Comment 22

[Brad Werth [:bradwerth]]

Attachment: Bug 1157592 Part 2: Specially treat the frames for the canvas custom content container to ensure they are added to the canvas and not the document root.

Review commit: https://reviewboard.mozilla.org/r/108364/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/108364/

Comment 23

[Brad Werth [:bradwerth]]

The proposed patch attaches the frames to the canvas. In SVG documents, we still get the bad rendering shown in attachment 8831324 [details]. I'm willing to try to debug the rendering of the frames, but I'm not sure how to inspect them using the dev tools -- if that's even possible. Mike, I'd appreciate it if you could review the way that /devtools/server/actors/highlighters/box-model.js builds the infobar node and give me some steps to inspect it.

Comment 24

[Mike de Boer [:mikedeboer]]

Brad, I'd be able to help here - but not today or tomorrow (PTO). Perhaps someone from devtools can assist here as well?

Comment 25

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 8831863 [details]
Bug 1157592 Part 1: Refactor out a helper function to add frames for anonymous content items.

https://reviewboard.mozilla.org/r/108362/#review109780

::: layout/base/nsCSSFrameConstructor.cpp:2942
(Diff revision 1)
> +nsCSSFrameConstructor::AddAnonymousItemsToFrame(nsFrameConstructorState& aState,
> +  nsIFrame* aFrame,
> +  nsTArray<nsIAnonymousContentCreator::ContentInfo>& aAnonymousItems)
> +{
> +  FrameConstructionItemList itemsToConstruct;
> +  nsContainerFrame* frameAsContainer = do_QueryFrame(aFrame);

Should probably assert this did not return null, and document accordingly in the header that aFrame must be known to be an nsContainerFrame.

Comment 26

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 8831864 [details]
Bug 1157592 Part 2: Specially treat the frames for the canvas custom content container to ensure they are added to the canvas and not the document root.

https://reviewboard.mozilla.org/r/108364/#review109782

::: layout/base/nsCSSFrameConstructor.cpp:9732
(Diff revision 1)
>        // because the frames will already have been built.
> +
> +      // Check for the special case of the canvas custom content container.
> +      if (aContent->IsElement()) {
> +        Element* contentAsElement = aContent->AsElement();
> +        if (contentAsElement->AttrValueIs(kNameSpaceID_None,

No, this isn't OK.  Any web page could create an element with that class, and then bad things would happen.

It might make more sense to check the following (in order of checks that are most likely to test false):

1) Check that mDocElementContainingBlock is a nsGkAtoms::canvasFrame
2) Cast to nsCanvasFrame and compare aContent to its GetCustomContentContainer().

::: layout/base/nsCSSFrameConstructor.cpp:9748
(Diff revision 1)
> +            nullptr,
> +            nullptr,

Why are those nullptr ok?  When we end up in ConstructAnonymousContentForCanvas, we hae done the following with our nsCSSFrameConstructorState:

1) Initialized it as you do here.
2) If mHasRootAbsPosContainingBlock called PushAbsoluteContainingBlock(mDocElementContainingBlock)
3) In the flex-root case pushed the document element's primary frame as an absolute containing block.

This last is arguably wrong and should get popped off ConstructAnonymousContentForCanvas.  But having mDocElementContainingBlock be the absolute container seems about right.  Please do so here.  I agree the float containing block should be null.

It's worth adding a comment here pointing to the other callsite and vice versa to make sure they stay in sync...

Comment 27

[Patrick Brosset <:pbro>]

(In reply to Brad Werth [:bradwerth] from comment #23)
> The proposed patch attaches the frames to the canvas.
Wow, really cool! Very exciting to see this progressing.
> In SVG documents, we
> still get the bad rendering shown in attachment 8831324 [details]. I'm
> willing to try to debug the rendering of the frames, but I'm not sure how to
> inspect them using the dev tools -- if that's even possible.
Unfortunately, devtools can't let you inspect the box-model highlighter's content. devtools is, as of now, unable to walk that part of the DOM. It can display native anonymous nodes within a <video> or <input range> for instance, but not the elements within the native anonymous content of the CanvasFrame.
> Mike, I'd
> appreciate it if you could review the way that
> /devtools/server/actors/highlighters/box-model.js builds the infobar node
> and give me some steps to inspect it.
This is definitely something Matteo can help you on.
The node infobar is built here
http://searchfox.org/mozilla-central/rev/4e0c5c460318fb9ef7d92b129ac095ce04bc4795/devtools/server/actors/highlighters/box-model.js#180-250
The code just builds a bunch of HTML elements that are then inserted into the CanvasFrame using document.insertAnonymousContent.
The screenshot looks like some CSS is either missing or doesn't apply correctly.
The CSS for the nodeinfobar is here
http://searchfox.org/mozilla-central/rev/4e0c5c460318fb9ef7d92b129ac095ce04bc4795/devtools/server/actors/highlighters.css#108-209

Comment 28

[Boris Zbarsky [:bzbarsky]]

> I'm willing to try to debug the rendering of the frames

One suggesting I'd have is hardcoding some DOM being attached as anon content and then using the layout debugger (run Firefox with the -layoutdebug option) to look at things like frame dumps and see whether at least those look as expected.

Comment 29

[Brad Werth [:bradwerth]]

Comment on attachment 8831863 [details]
Bug 1157592 Part 1: Refactor out a helper function to add frames for anonymous content items.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/108362/diff/1-2/

Comment 30

[Brad Werth [:bradwerth]]

Comment on attachment 8831864 [details]
Bug 1157592 Part 2: Specially treat the frames for the canvas custom content container to ensure they are added to the canvas and not the document root.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/108364/diff/1-2/

Comment 31

[Brad Werth [:bradwerth]]

Comment on attachment 8831863 [details]
Bug 1157592 Part 1: Refactor out a helper function to add frames for anonymous content items.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/108362/diff/2-3/

Comment 32

[Brad Werth [:bradwerth]]

Comment on attachment 8831864 [details]
Bug 1157592 Part 2: Specially treat the frames for the canvas custom content container to ensure they are added to the canvas and not the document root.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/108364/diff/2-3/

Comment 33

[Brad Werth [:bradwerth]]

Comment on attachment 8831863 [details]
Bug 1157592 Part 1: Refactor out a helper function to add frames for anonymous content items.

https://reviewboard.mozilla.org/r/108362/#review109780

> Should probably assert this did not return null, and document accordingly in the header that aFrame must be known to be an nsContainerFrame.

I chose to sidestep this a bit by making the method signature declare nsContainerFrame* as the parameter type, leaving the do_QueryFrame in ConstructAnonymousContentForCanvas and putting the assert there.

Comment 34

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 8831864 [details]
Bug 1157592 Part 2: Specially treat the frames for the canvas custom content container to ensure they are added to the canvas and not the document root.

https://reviewboard.mozilla.org/r/108364/#review110066

r=me

Comment 35

[Mike de Boer [:mikedeboer]]

The way I'm checking if there are visual changes caused by these patches by loading https://bug1294843.bmoattachments.org/attachment.cgi?id=8780694 and seeing if I can use find-in-page. So far, I can't. I hope Matteo is able to lend a hand here soon!

Comment 36

[Matteo Ferretti [:zer0] [:matteo]]

Brad, let me know what you need specifically, and I'll help you in any way I can! I really want to have this bug landed. :)

Comment 37

[Brad Werth [:bradwerth]]

Comment on attachment 8831863 [details]
Bug 1157592 Part 1: Refactor out a helper function to add frames for anonymous content items.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/108362/diff/3-4/

Comment 38

[Brad Werth [:bradwerth]]

Comment on attachment 8831864 [details]
Bug 1157592 Part 2: Specially treat the frames for the canvas custom content container to ensure they are added to the canvas and not the document root.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/108364/diff/3-4/

Comment 39

[Brad Werth [:bradwerth]]

Rebased the patch in preparation of landing, but this has suffered some bit rot. There's now a failure at https://dxr.mozilla.org/mozilla-central/source/layout/painting/FrameLayerBuilder.cpp#4116. The debugger shows that a display item has been created for an nsBlockFrame that has an mParent pointing to the canvas, but the display item has no clip chain. The canvas DOES NOT include this nsBlockFrame in its children, so some incorrect frame creation has occurred.

Comment 40

[Brad Werth [:bradwerth]]

(In reply to Brad Werth [:bradwerth] from comment #39)
> The canvas DOES NOT include this nsBlockFrame in its children, so some incorrect frame creation has occurred.

I've since realized that the child may be in some other child list (besides mFrames), so this is not necessarily an error condition.

Comment 42

[Patrick Brosset <:pbro>]

From bug 1396198:

Steps to reproduce:

Open a page: Content-Type image/svg+xml.
Open dev tools.
Toggle ruler option, no ruler lines visible.
Toggle portion ruler, no ruler line visible.

Actual results:

Toggle ruler option, no ruler lines visible.
Toggle portion ruler, no ruler line visible.

Comment 43

[Brad Werth [:bradwerth]]

I'll pick this up again and try to get it completed and landed. Sorry for it getting lost!

Comment 44

[Brad Werth [:bradwerth]]

Comment on attachment 8831863 [details]
Bug 1157592 Part 1: Refactor out a helper function to add frames for anonymous content items.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/108362/diff/4-5/

Comment 45

[Brad Werth [:bradwerth]]

Comment on attachment 8831864 [details]
Bug 1157592 Part 2: Specially treat the frames for the canvas custom content container to ensure they are added to the canvas and not the document root.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/108364/diff/4-5/

Comment 46

[Brad Werth [:bradwerth]]

Okay, rebased this and carved out all the bit-rot. We're back to where we were at comment 27 -- the anonymous content container is now added correctly to the tree, but the tooltips for SVG elements do not render correctly (as shown in attachment 8831324 [details]). I need help from devtools team to fix this. Matteo, would you please investigate this issue? Is there more needed from the platforms to get the tooltips drawing correctly?

Comment 47

[Brad Werth [:bradwerth]]

Comment on attachment 8831864 [details]
Bug 1157592 Part 2: Specially treat the frames for the canvas custom content container to ensure they are added to the canvas and not the document root.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/108364/diff/5-6/

Comment 48

[Brad Werth [:bradwerth]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=f4398cbb4a9ee1636749853e59df77a8b3dd1e17

Comment 49

[Brad Werth [:bradwerth]]

Comment on attachment 8831863 [details]
Bug 1157592 Part 1: Refactor out a helper function to add frames for anonymous content items.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/108362/diff/5-6/

Comment 50

[Brad Werth [:bradwerth]]

Comment on attachment 8831864 [details]
Bug 1157592 Part 2: Specially treat the frames for the canvas custom content container to ensure they are added to the canvas and not the document root.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/108364/diff/6-7/

Comment 51

[Matteo Ferretti [:zer0] [:matteo]]

(In reply to Brad Werth [:bradwerth] from comment #46)

> Matteo, would you please investigate this issue? Is there more
> needed from the platforms to get the tooltips drawing correctly?

I'll try to test it and see if I can gather some information why this is happening, likely tomorrow.

Comment 52

[Matteo Ferretti [:zer0] [:matteo]]

I tried to apply the first patch but it got rejected; maybe it needs a rebase?

Comment 53

[Brad Werth [:bradwerth]]

Comment on attachment 8831863 [details]
Bug 1157592 Part 1: Refactor out a helper function to add frames for anonymous content items.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/108362/diff/6-7/

Comment 54

[Brad Werth [:bradwerth]]

Comment on attachment 8831864 [details]
Bug 1157592 Part 2: Specially treat the frames for the canvas custom content container to ensure they are added to the canvas and not the document root.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/108364/diff/7-8/

Comment 55

[Brad Werth [:bradwerth]]

Rebased and posted.

Comment 56

[Brad Werth [:bradwerth]]

Comment on attachment 8831863 [details]
Bug 1157592 Part 1: Refactor out a helper function to add frames for anonymous content items.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/108362/diff/7-8/

Comment 57

[Brad Werth [:bradwerth]]

Comment on attachment 8831864 [details]
Bug 1157592 Part 2: Specially treat the frames for the canvas custom content container to ensure they are added to the canvas and not the document root.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/108364/diff/8-9/

Comment 58

[Matteo Ferretti [:zer0] [:matteo]]

Attachment: svg and highlighters

Thanks Brad for the rebase!

After the chat on IRC, yesterday night, I was able to make a build.
For future reference: I updated everything (rustup, run `mach bootstrap`, etc); but I forgot to reinstall the Apple Developer Tools (`xcode-select  --install`), that was the culprit. Apparently the version of llvm I had didn't match the one required (but the bootstrap didn't warn me about it).

Said that, I think the issue we're having on this bug are not merely related to CSS that are not properly applied; but something more deeper than that. I made the video in attachment to show you at least the major issue.

The video shows the steps, but basically I enabled on a fresh profile the rulers and the measuring tool: the rulers are pure SVG, and they're rendered properly. The measuring tool, as the box model, contains a mix of SVG and HTML nodes. The tooltip, is HTML: as you can see, it's definitely not painted correctly from the engine, it's not a matter of CSS applied, since it shouldn't leave the "trace" when the mouse is moving.
When I measure an area, the SVG part of the measuring tool is rendered properly as you can see. However, it seems that also the pointer-events are a bit messed up, but that could be unrelated (the area change color when I pass the mouse over, when it shouldn't).

As a side note, I tried to do the test on this URL too:

https://upload.wikimedia.org/wikipedia/en/thumb/4/49/Mozilla_Mascot.svg/641px-Mozilla_Mascot.svg.png

However, when a open the developer toolbox, the image instead of resizing is disappearing.
Not sure if it's related, but it's worth to mention.

Hope this will help, let me know.

Comment 59

[Matteo Ferretti [:zer0] [:matteo]]

(In reply to Matteo Ferretti [:zer0] [:matteo] from comment #58)
> When I measure an area, the SVG part of the measuring tool is rendered
> properly as you can see.

Forgot to mention, is rendered properly but also that part has the "trace" issue - when I measure another portion the previous one should be gone, since I'm re-positioning the same SVG elements.

Comment 60

[Brad Werth [:bradwerth]]

Thank you for your thorough testing. I've come to the same conclusion that there are more serious issues with the patch that I need to resolve. The tests that are failing on the try runs indicate that the code is not recreating the anonymous content container properly. I'll needinfo? you again when I get the patch healthier (if there are still problems with the display of tooltips and other elements).

Comment 61

[Brad Werth [:bradwerth]]

Comment on attachment 8831864 [details]
Bug 1157592 Part 2: Specially treat the frames for the canvas custom content container to ensure they are added to the canvas and not the document root.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/108364/diff/9-10/

Comment 62

[Brad Werth [:bradwerth]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=539dda529d80aa2b3400c7c0e9cd8d793729f757

Comment 63

[Brad Werth [:bradwerth]]

Attachment: Bug 1157592 Part 1: Refactor out a helper function to add frames for anonymous content items.

Review commit: https://reviewboard.mozilla.org/r/186582/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/186582/

Comment 64

[Brad Werth [:bradwerth]]

Comment on attachment 8831864 [details]
Bug 1157592 Part 2: Specially treat the frames for the canvas custom content container to ensure they are added to the canvas and not the document root.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/108364/diff/10-11/

Comment 65

[Emilio Cobos Álvarez (:emilio)]

The approach here was somewhat misguided. I took a look and found that the root cause of this is because it's the root cause of bug 1462742.

Comment 66

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1157592: Make InsertAnonymousContent load all the relevant stylesheets in SVG documents.

The underlying issue here is that the rule that makes the custom content
container abspos is in ua.css, and we don't load that for SVG documents.

Similarly, this fixes all the markers and such, that would be inline because of
the lack of html.css etc.

This fixes the root cause of bug 1462742, as well, so I added a few assertions
that should replace the wallpaper there. The reason we're guaranteed to be oof
is because top-layer implies that via StyleAdjuster::adjust_for_top_layer.

As an aside, the fact that AccessibleCaret calls into InsertAnonymousContent
from frame construction makes me extremely nervous, but it already does all sort
of other pretty nasty stuff... I'll file and fix.

Review commit: https://reviewboard.mozilla.org/r/250588/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/250588/

Comment 67

[Emilio Cobos Álvarez (:emilio)]

That fixes all the issues that have showed up in comments so far, if somebody confirms it it'd be awesome.

Comment 68

[Patrick Brosset <:pbro>]

(In reply to Emilio Cobos Álvarez [:emilio] from comment #67)
> That fixes all the issues that have showed up in comments so far, if
> somebody confirms it it'd be awesome.
That sounds great Emilio! Any chance you could push to try so I can try it out quickly?

Comment 69

[Emilio Cobos Álvarez (:emilio)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=66314a598d526a27e88d442d8c949ee761e764f2 should contain this and the followup cleanup bug 1468133, and should be green on try.

Comment 70

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 8984792 [details]
Bug 1157592: Make InsertAnonymousContent load all the relevant stylesheets in SVG documents.

https://reviewboard.mozilla.org/r/250588/#review257612

Comment 71

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/c25c1b63695a
Make InsertAnonymousContent load all the relevant stylesheets in SVG documents. r=bz

Comment 72

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/c25c1b63695a

Comment 73

[Mark Turner]

Thanks for this fix!

Yaaaaay!! ;)

Comment 74

[Rares Doghi, Desktop QA]

Hi, Can someone provide some steps for this issue, I'm not sure what this fix is for and the links from the comments are no longer available.

Maybe just a web page this can be verified on.

I tried to see the highlighter on this page https://static.mozilla.com/moco/en-US/images/mozilla_eoy_2013_EN.svg and without any success, Nothing I'm hovering over in DevTools is highlighted in the page, however on IGN.com an html page it highlights everything correctly.

Comment 75

[Emilio Cobos Álvarez (:emilio)]

It may have broken for an unrelated reason. Before this fix the highlighter was visible but wrong, this fixed it, but when I try to inspect stuff now the highlighter is hidden (because it has the hidden attribute).

Patrick would know what's going on there I presume.

Comment 76

[Patrick Brosset <:pbro>]

I can't get it to work in 62 either, which is the version this bug landed in. So I'm confused because this was verified by at least 2 people then.

I tested on 60, 62, 64, 65, 66. On this document: data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg"><circle cx="50" cy="50" r="15"/></svg>
I also tested on https://www.w3.org/Graphics/SVG/svglogo.svg

Comment 0 of this bug mentioned attachment 8548868 [details] which I can't seem to open anymore.

Comment 77

[Patrick Brosset <:pbro>]

(In reply to Patrick Brosset <:pbro> from comment #76)
> Comment 0 of this bug mentioned attachment 8548868 [details] which I can't
> seem to open anymore.
Wait, I could open it now, and same result, I can't get the highlighter to show on 62.

Comment 78

[Rares Doghi, Desktop QA]

Hi Patrick, should we reopen this issue ?

Comment 79

[Patrick Brosset <:pbro>]

Yes you are right, we should.
So, reopening now based on comment 74 and comment 76.

Comment 81

[Emilio Cobos Álvarez (:emilio)]

This is fixed now / at some point.