Bug 1164338 added the RestyleTimelineMarker to dump the restyle hint in timeline tab, but it is not enough for app developer to know which dom elements cause the restyle. To help app developers, it is better to provide the xpath, class name or id of dom elements.

This would be great -- any ideas of how to add it from layout? (I'm unfamiliar with layout code)

(In reply to Jordan Santell [:jsantell] [@jsantell] from comment #1) > This would be great -- any ideas of how to add it from layout? (I'm > unfamiliar with layout code) Here is some example to dump the class and id information. https://dxr.mozilla.org/mozilla-central/source/layout/base/nsLayoutDebugger.cpp?from=nsLayoutDebugger.cpp&case=true#149 I already had a path to add the class name nad id of dom elements, but not every dom element defines the class name and id. Therefore, it would be better to provide the xpath of dom elements too. Checking how to dump the xpath.

Storing class name / id / xpath would have the limitation of these values changing after the restyle but before the user views and interacts with it. But it does sounds like useful information when debugging the restyle. If there were a way to store a reference to the node itself that would be the best for UX since we could then highlight the element on the page or jump to it in the inspector

Highlighting/selecting in inspector is a desirable feature. But it must also work when loading from file, and if we can have some sort of serializable information (like an xpath at the time of recording), that'd be useful too, even if only accurate during time of sampling

(In reply to Jordan Santell [:jsantell] [@jsantell] from comment #4) > Highlighting/selecting in inspector is a desirable feature. > > But it must also work when loading from file, and if we can have some sort > of serializable information (like an xpath at the time of recording), that'd > be useful too, even if only accurate during time of sampling Good point. Also if we store class/id then we could generate a lightweight preview of the node like we generate for the webconsole in _renderElementNode: https://github.com/mozilla/gecko-dev/blob/master/browser/devtools/webconsole/console-output.js#L3078

Storing the xpath and a preview of the node sounds good since we want to be able to export/import records. There's a new UI component that can be used for generating a nice <tag id="theId" class="theClass"> preview that has been added to the animationinspector panel: http://mxr.mozilla.org/mozilla-central/source/browser/devtools/animationinspector/components.js#276 It may need some tweaking, but it can almost be reused as is to generate node previews as long as you have a reference to the node itself and to the inspector. So in the performance tool UI, we could use the xpath to get a NodeFront (using the WalkerActor, adding a new method). If the corresponding node still exists then we can highlight it in the page and even select it in the inspector just like the webconsole and variableview do.

(In reply to Patrick Brosset [:pbrosset] [:patrick] [:pbro] from comment #6) > So in the performance tool UI, we could use the xpath to get a NodeFront > (using the WalkerActor, adding a new method). If the corresponding node > still exists then we can highlight it in the page and even select it in the > inspector just like the webconsole and variableview do. I'm worried about this returning an incorrect result and showing the wrong thing in the case of the selector still being valid but pointing to a different node. For example, if the node was the nth child in a big list of items when the marker was added, but is now the n+1th child, we would be highlighting the wrong thing. It also wouldn't make sense at all if a profile was imported on a different page. If it's possible to keep a reference to the node itself in the marker (but obv not export it), that would be a nice enhancement on top of the xpath + preview if the profile was taken in the same session. If not (or if the node no longer exists), then just don't attempt to do the highlighting / linking.

What chrome does is display an xpath-looking link that will select the element on the page if still in the same context. If loading from disk or navigating to a new page, these links are rendered differently (like "[ BUTTON ]" instead of an underlined "button") indicating they no longer link to the document. Other than that they're the same (and Layout Root's in layout markers no longer are listed in data if the document is stale, which seems like a bug).

Now I'm able to get the xpath of dom elements which have style changes in gecko. But the index is not matched with xpath that I got from inspector because there are some text node(for new line) inserted in the content tree. Therefore, the index of the following div elements are not matched between gecko and inspector. Need to bypass these text nodes to count the element index. body@0x12795ba60 state=[40000010000] flags=[00100000] primaryframe=0x1250aa398 refcount=13< Text@0x124bcd0d0 flags=[07800000] primaryframe=0x0 refcount=1<\u000a> div@0x124bcd160 id="section" class="class1" state=[40000010000] flags=[00100400] ... Text@0x124bcd8b0 flags=[00000000] primaryframe=0x129d2f900 refcount=2<\u000a\u000a> div@0x124bcd940 id="section2" style="width: 350px;" state=[40000010000] flags=[00100000] primaryframe=0x129d2fa10 refcount=10<

Triaging. Filter on ADRENOCORTICOTROPIC (yes).