The details on how this would work are very fuzzy.

For example, what happens if the content of the page is dynamic (ie: element moves or does not exist for some loads)?

For now the best we have is you can copy the XPath or Selector and then you could write some javascript to read a parameter out of a url and scroll it into view based on the parameter.

Thanks, but I don't see how we could accomplish this :-/

I thought I described the details of how it would work very well, but to be more precise:
* The menu will include a new "Navigate to Element" item if, at the time of opening it, either the "id" attribute of the context element is owner-document-unique or the context element is an <a> element and its "name" attribute does not match that of any other <a> element in the owner document (essentially inverting https://html.spec.whatwg.org/multipage/browsers.html#the-indicated-part-of-the-document ).
* Upon activation of that item, the
https://html.spec.whatwg.org/multipage/browsers.html#dom-location-assign algorithm is invoked with a relative URL consisting only of a fragment component corresponding to the unique attribute (preferring "id" in the case where both are), which will scroll to the fragment.
It's _exactly_ like `location.assign("#…")`, and dynamic content should be fine because there's no opportunity for change until after the navigation (or at least, no issues that wouldn't already have analogs for "Scroll into View").

Assuming the above sufficiently resolves any fuzziness, are there any hurdles that would impede implementation? It looks to me like it could be added at the end of populateTagContextMenu (https://github.com/ChromeDevTools/devtools-frontend/blob/92d413e3be1a7ed28e36c64b82c1152d8fb0b8db/front_end/elements/ElementsTreeElement.js#L459 ) with code like
```
var fragment = this.getUniqueFragment();
if (fragment) {
  this.populateNavigateToElement(contextMenu, fragment);
}
```