It should be noted that the problem is specific to that Adobe site because it hides the page body by default via CSS, checks the hash part and scrolls to the anchor using its javascript.

Non-interactive pages with anchors are displayed/scrolled correctly regardless of being opened in background.

Able to reproduce this issue on Mac 10.12.6, Win-10 and Ubuntu 14.04 using chrome reported version #61.0.3163.79 and latest canary #63.0.3214.0.

This is a non-regression issue as it is observed from M50 old builds. 

Hence, marking it as untriaged to get more inputs from dev team.

Thanks...!!

This is not related to the NTP. Not sure how to classify it.

I can repro in 61.0.3163.91, with and without PlzNavigate (BrowserSideNavigation).

The bug seems to repro for both middle-click and "Open in new tab" from the context menu (which use different code paths), but not for shift-click or "Open in new window" from the context menu.  That suggests it only affects links opened specifically in background tabs.  It affects both bookmarks and links in normal web pages.

Comment 2 is interesting.  For links to a simpler page like https://www.chromium.org/developers#TOC-Blink, the page *does* scroll when opening in the background, but it scrolls to the wrong place (too far).  It should show "Blink" at the top, but when opening the link in a background tab, it jumps all the way to "Web Platform Tests" and scrolls "Blink" well off the top of the page.

I suspect this may be related to some scrolling logic and/or optimizations for background tabs?  Adding chrisha@ and panicker@ to help triage, and pnoland@ in case scroll anchoring might be involved.

we haven't made any recent changes for background tabs that I am aware of that might cause this issue.

I don't think this is scroll anchor related, nor is it apparent to me that it's a Chrome bug at all. As #2 points out, the page has custom logic for scrolling to elements using the hash fragment. Furthermore, the page in question doesn't have an element with the id "#main-pars_text_8" at all. So the failure to scroll to the desired location in the page is purely a failure of this custom logic. I can only speculate as to why this works when the page is foreground loaded but not otherwise.

Comment 7: I'd still be concerned about scrolling to the wrong location in the simpler page (from comment 5).  Seems like it's worth understanding why there's a difference between foreground and background, since I wouldn't otherwise expect it here.

I'll request a bisect to see if it's a regression, but maybe it's just a matter of Blink not being able to scroll properly if it doesn't actually paint the page?

I agree that if what you describe in #5 is happening reliably then it's concerning; FWIW I wasn't able to repro that behavior in any of the milestones or platforms I tried. 

Interesting-- the Chromium link issue is not currently repro'ing for me from the bookmarks bar, but it does for links on a web page when DevTools is open!

More specific steps (based on what I saw in #5):
1) Visit http://csreis.github.io/tests/
2) Right click the first link and choose Inspect (opening DevTools docked within the tab).
3) Double click the href for the link and replace it with https://www.chromium.org/developers#TOC-Blink.
4) Middle click the link, while DevTools is still open.

Repros on both 61.0.3163.91 and 63.0.3215.0.

I wonder why the presence of DevTools in one tab affects how a newly opened background tab scrolls?

Tested the issue with steps mentioned in comment#10 and is reproducible on latest stable 61.0.3163.91 and latest canary 63.0.3215.0 using Ubuntu 14.04,Windows 10 and Mac 10.12.1.

Issue is seen from M50 series[50.0.2661.0]. Attaching screencast for reference..

Deleted: Issue 764605.ogv 1.6 MB

	Issue 764605.ogv 1.6 MB View Download

Note that the platform devtools scroll issue doesn't happen if it is docked at the bottom or in a new window or the page is opened in an incognito window or a new window (ie. it only happens on a new tab).

dgozman@ any idea?

This is due to this [1] line. DevTools docked to the right changes the width of active tab, newly opened tab gets that width and scrolls to the anchor. Once you switch to it, we resize it because there is no DevTools open for new tab, and scroll position changes. You can even see briefly the old-sized content sometimes.

Although there is a TODO next to the problematic line, it has been there for a long time so changing this significantly will surely break things. I don't see an easy way to fix the DevTools usecase, so it's probably not worth doing. This is a first time I see someone complain.

[1] https://cs.chromium.org/chromium/src/chrome/browser/ui/tabs/tab_strip_model.cc?rcl=769a874fb57870662933ad0a7083b4e50c838149&l=818

Thanks dgozman@, that explains the problem in  issue #5 . The original issue seems likely to be a page issue and I can't repro it with 63.0.3230.0, perhaps the page itself was fixed? Any objections to closing this?

^^ erm, "that explains the problem in _comment_ #5"

The NextAction date has arrived: 2017-10-12