971674 - Hovering over node in inspector should scroll into view the corresponding area in document.

Status: RESOLVED WONTFIX

(DevTools :: Inspector, defect)

Description

[Dane MacMillan [:danemacmillan]]

The document should scroll the relevant area into view when hovering over its corresponding node in the inspector, or (if that behaviour is too shocking) only scrolling the relevant document area into view when a node in the inspector has been clicked. At the moment the dashed selector highlighter just sort of plants itself against the boundaries of the viewport when the area in the document is out of view, which is what all inspector tools do at the moment, but shouldn't really. Not to mention, the reverse does happen: when hovering over sections in the document, the corresponding inspector nodes are scrolled into view.

I figure if when searching for nodes in the search bar can cause the document to scroll the found area into view, then it shouldn't be too far off from that.

Comment 1

[Patrick Brosset <:pbro>]

You're right, it should do that and in fact, it's supposed to do it on click already.
It turns out it doesn't always work for some reason.

To try this:
- open the inspector on this bugzilla page
- in the markup-view, click on the #footer element
==> Nothing happens, the element isn't scrolled into view
- now, scroll down to the bottom of the page
- in the markup-view, click on the #usermenu_widget element
==> This time, the element is scrolled into view

Comment 2

[Dane MacMillan [:danemacmillan]]

I tried what you suggested--on both a Win7 and OSX Mavericks machine--and neither machine performed the scroll. The only time scrolling the document area into view works is when searching for the node in the search bar. For example, I could type #usermenu_widget into the search bar and the page will promptly scroll the document area into view, and if there were multiple nodes found, the document will always scroll each found corresponding node area into view.

I've never seen the described/desired behaviour function. It will be awesome when it does, though!

Comment 3

[Jeff Griffiths (:canuckistani) (:⚡︎)]

Scrolling around on hover seems like it might be really distracting; scrolling on click I thought was the behaviour. Did this ever work?

Comment 4

[Jeff Griffiths (:canuckistani) (:⚡︎)]

It does work in Beta (27) quite well, I think with the introduction of the new inspector in 29 something's gotten sketchier.

Comment 5

[Dane MacMillan [:danemacmillan]]

I'm posting bug 984848 as it may relate, particular the second comment on that bug.

When the page loads or reloads with the Developer Tools open, the last selected node (or the body node if none explicitly selected), will momentarily flash the inspector outlines on the document AND scroll that node into view. If working on pages with a scrollbar, and in particular working on a part of a page outside the visible viewport (so scrolled down, for example), and refresh is hit, the page will scroll up to the location of the last selected node (or body, as mentioned). This is definitely counter to expectations, and a quirk just small enough to drive one mad. This started about a week ago. A feature I'm developing is near the bottom of a page, and so I have to refresh often, and because the Developer Tools are open, this means the document is scrolled back to the top on every refresh, with the inspector outline of the body node flashing momentarily, then I have to scroll down to the section of the document I'm working on again.

If anything, this shows that a small but important distinction of sorts will have to be made when considering when to scroll (which is currently broken, with the exception of the bug just described), and when to keep the viewable section of the document in view.

Comment 6

[Dane MacMillan [:danemacmillan]]

As a side note, I don't think the inspector highlighter should flash on page at all on refresh or page load, which I think would solve the issue. Like I wrote, it started about a week back, so the fix may not be too involved, though I won't make assumptions.

Comment 7

[Patrick Brosset <:pbro>]

(In reply to Dane MacMillan from comment #6)
> As a side note, I don't think the inspector highlighter should flash on page
> at all on refresh or page load, which I think would solve the issue. Like I
> wrote, it started about a week back, so the fix may not be too involved,
> though I won't make assumptions.
I agree, it shouldn't do that at all when refreshing the page. And I think that's the way it works in Aurora. So something we changed when working on the new box model highlighter might have broken this.
I think the investigation should start in markup-view.js/MarkupView._shouldNewSelectionBeHighlighted

Comment 8

[Jeff Griffiths (:canuckistani) (:⚡︎)]

I'm tempted to WONTFIX this specifically because I do not think we want to do a scrol on hover. I think instead selecting the node should scroll it into view ( in fact, this used to work! )

Comment 9

[Ole Ersoy]

I would be really grateful if the scroll on select starts working.  It will make it very easy to review the page and markup settings at the same time.  Right now when reviewing markup using the inspector, I have to manually scroll the page to the markup location.

Comment 10

[Jeff Griffiths (:canuckistani) (:⚡︎)]

(In reply to Ole Ersoy from comment #9)
> I would be really grateful if the scroll on select starts working.  It will
> make it very easy to review the page and markup settings at the same time. 
> Right now when reviewing markup using the inspector, I have to manually
> scroll the page to the markup location.

You shouldn't need to manually scroll, you can now right-click on a node and scroll it into view:

https://bugzilla.mozilla.org/show_bug.cgi?id=901250

Aside: I'm tempted to close this as WONTFIX - we have decided that the context menu feature is 'good enough'. Patrick?

Comment 11

[Patrick Brosset <:pbro>]

I agree.
Also, websites tend to use the scroll position more and more to play animations or load content and what not. So making the inspector scroll the document sounds like something we'd want to remove later anyway. One might want to make sure the document doesn't scroll while inspecting it, to ensure css rules and dom elements don't change.
I do agree however that it's frustrating to have to go through 2 steps to see both a node in the inspector and in the page: 1) select in the inspector 2) scroll the node into view.
Maybe adding a keyboard shortcut for the "scroll into view" context menu would be a nice addition (we already have 'h' to hide/show, and 'del' to remove the node, we could add 's' to scroll into view).
Filed bug 1203147 for this.