Tested on Pixel 2 XL Android 8.1.0 using the latest Stable #67.0.3396.81 & Canary #69.0.3453.2 and was not able to reproduce the issue by following the steps provided. Attached the screen cast for reference.

steffen.weber@ -- Please let us know if we have missed anything. Also, please share the device details where the issue is reproduced. Is the issue consistently reproduced? Could you also please share the screen cast of the issue for better understanding.

Thanks!

Deleted: 850868.mp4 3.0 MB

	850868.mp4 3.0 MB View Download

Thank you for the reply. As far as I can tell from the screencast, there seems to have been a misunderstanding. It seems like you haven't actually opened the anchor link in the first paragraph in a new tab (step 2).

I've attached a screencast that shows the problem on my Nexus 5X with Android 8.1 using Chrome 66.

Mozilla/5.0 (Linux; Android 8.1.0; Nexus 5X Build/OPM6.171019.030.B1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.158 Mobile Safari/537.36

Deleted: Chrome for Android Bug 850868.mp4 6.0 MB

	Chrome for Android Bug 850868.mp4 6.0 MB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

steffen.weber@ -- From the sample HTML file provided by you in original comment, when we long tap on the link "this anchor link" doesn't give the option "Open in new tab". So, request you to provide the complete URL on which you are performing the actions as in Comment #3.

Deleted: 850868.png 254 KB

	850868.png 254 KB View Download

I have uploaded the test case here: https://www.computerbase.de/chrome-bug-850868.html

(Maybe you don't see the option "Open in new tab" because of the "content://" URI scheme visible in your screenshot.)

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Tested the issue in Android and able to reproduce the issue. 

Steps Followed:
1. Launch Chrome.
2. Navigate to any URL - https://www.computerbase.de/chrome-bug-850868.html
3. Long tap on the link - ‘this anchor link’.
4. Tap on the option ‘Open in new tab’.
5. Switch to the new tab in which the page is opened.
6. Observed that page is scrolled completely to the bottom of the screen. Instead it should scroll to the bolded text.

Chrome versions tested:
66.0.3359.158(Stable), 69.0.3456.0(Canary)

OS:
Android 8.1.0

Android Devices:
Pixel XL

Using the per-revision bisect providing the bisect results,
Good Build - 65.0.3287.0 (522296)
Bad Build - 65.0.3288.0 (522666)

Unable to provide the per-revision bisect details as in all the builds generated when user long tap on the link ‘this anchor link’, ‘Open in new tab’ option is not displayed.
Hence, in the above range, suspecting the below CL
https://chromium.googlesource.com/chromium/src/+/8b5d92a450f48ccb7ea31cb2e88478868959fbea

asimjour@ --  Could you please look into the issue, pardon me if it has nothing to do with your changes and if possible please assign it to owner concerned.

Please navigate to below link for log's and video--
go/chrome-androidlogs/850868

Thanks!

My change only affects scrolling when user is browsing in VR and is using VR controller.

arthursonzogni@ Could you please take a look? Looking at that range I guess the issue might be related to your changes.
Please assign it back to me (or the owner of the CL that looks more related) if it has nothing to do with your change.

Thanks

Okay, I will take a look.
Could you please tell me which change I made you are thinking about?

AFAIU the range is:
https://chromium.googlesource.com/chromium/src/+log/65.0.3287.0..65.0.3288.0?pretty=fuller&n=10000

I only have one CL here: https://chromium.googlesource.com/chromium/src/+/3a4ca9f52450a1f27422978e044d9cc3aa5fd1d7

Is it this one?

I did a bisection and found the appropriate owner:
~~~[ git bisect log]~~~
git bisect start
# good: [7ec22e136c3cf69917151bcd8dbf8e5ba681e035] Publish DEPS for Chromium 65.0.3287.0
git bisect good 7ec22e136c3cf69917151bcd8dbf8e5ba681e035
# bad: [72a06b8e69729d4905659c2dad133d5a11c9d13d] Publish DEPS for Chromium 65.0.3288.0
git bisect bad 72a06b8e69729d4905659c2dad133d5a11c9d13d
# good: [6f81258f0351810250e0c48cd36a3ba7124a2fb6] Revert "Reland: Media Controls: Double tap on either side to jump"
git bisect good 6f81258f0351810250e0c48cd36a3ba7124a2fb6
# good: [0639c753f9edfb3b5ed57296f16f956c7de6e98e] Use Aapt2 for final apk resource packaging
git bisect good 0639c753f9edfb3b5ed57296f16f956c7de6e98e
# bad: [2a4fd9674bf8898ca70ced48ba4c121ff5ceb703] Autofill fields with values added by website.
git bisect bad 2a4fd9674bf8898ca70ced48ba4c121ff5ceb703
# bad: [5246fc972e1143ad86e10c985d44257c8d6ae535] Roll src/third_party/pdfium/ bb6ecbad9..39a076f19 (2 commits)
git bisect bad 5246fc972e1143ad86e10c985d44257c8d6ae535
# good: [d9ab2fcda0538f56bb05c71a0d6c6375cb80ed71] VR: Final tweaks to make omnibox work.
git bisect good d9ab2fcda0538f56bb05c71a0d6c6375cb80ed71
# good: [fdfe23e1ab3f08231bc3c45badb6ca07d5814e3c] Web Locks API
git bisect good fdfe23e1ab3f08231bc3c45badb6ca07d5814e3c
# bad: [9e593546c4186256c858e5e786bd51fa76a51dbd] Disable flaky tests on viz
git bisect bad 9e593546c4186256c858e5e786bd51fa76a51dbd
# bad: [70fb72929fe3918329e4b938e45bc1ddd03e6f0f] Update Chrome Proxy integration test name to match what the test is checking
git bisect bad 70fb72929fe3918329e4b938e45bc1ddd03e6f0f
# bad: [708d46e3653a5ae94414689b885051333bf59e35] Prevent CCT/Webapp tab from resizing incorrectly
git bisect bad 708d46e3653a5ae94414689b885051333bf59e35
# good: [ad33ed3adb4ffc05903c1d4095ff264579583437] Disable parallelism on telemetry_unittests everywhere
git bisect good ad33ed3adb4ffc05903c1d4095ff264579583437
# first bad commit: [708d46e3653a5ae94414689b885051333bf59e35] Prevent CCT/Webapp tab from resizing incorrectly
~~~

The regression started in:

~~~
commit 708d46e3653a5ae94414689b885051333bf59e35 (refs/bisect/bad)
Author: Jinsuk Kim <jinsukkim@chromium.org>
Date:   Thu Dec 7 20:00:39 2017 +0000

    Prevent CCT/Webapp tab from resizing incorrectly
    
    This CL removes a spurious |WebContents.setSize()| at
    the tab initialization that sets a wrong view size to
    fix the bug of giving a wrong view height for CCT/Webapp.
    
    Bug:  789260 
    Change-Id: Ie93e81b4fd9f1387e121105dd048c22015238f12
    Reviewed-on: https://chromium-review.googlesource.com/795479
    Commit-Queue: Jinsuk Kim <jinsukkim@chromium.org>
    Reviewed-by: Ted Choc <tedchoc@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#522517}

~~~

Looking at the description, I am quite confident this is the right one.

+owner jinsukkim@. Hi Jinsuk, could you please take a look?
+CC tedchoc@

Mine indeed. Thanks for bisecting Author!

-arthursonzogni, asimjour

Started by reverting the culprit CL. Verified the problem then goes away.

What's hard is figure out how to test the old sizing problem ( Issue 789260 ) that the CL landed for. It was reproducible only on webapp-capable site that implements page scroll on its own by overriding Chrome's default behavior. https://chromium-review.googlesource.com/c/chromium/src/+/795479#message-3fa21724cc0a50f55b7bb6aaf6574f68a4aea7e8

But the site (Google news) seems to have changed its property - the home screen shortcut now always launches as a tab in Chrome, not as webapp/singleTabActivity, so it's not suitable for testing any more. No idea what other sites come with such scroll implementation.

For debugging purpose, here's what I tried. https://crrev.com/c/1119623

- Open a webapp site (https://hackerweb.app for instance)
- Create a home screen shortcut
- Launch the site from the shortcut

The patch overrides the url of the shortcut to https://news.google.com so it will launch the site in webapp mode instead. But I don't see the sizing problem any more in this way on that site. Maybe this is not 100% same as launching the site as it was reported in  Issue 789260 .

tedchoc@ I need to make sure not to introduce regression on sizing while fixing the anchor link bug. Do you by any chance know sites other than google news that I can reproduce the sizing bug with? Any suggestions I can try out would be welcome.

 

It's not easy to find sites that help me verify the change will work without regression. I'm hoping I can land the CL first and then act on any bugs it may cause, which I believe is more efficient than spending more time searching for sites that will be affected.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b5e60ea4cda5339f48e30480aa1e29a57f1a0f68

commit b5e60ea4cda5339f48e30480aa1e29a57f1a0f68
Author: Jinsuk Kim <jinsukkim@chromium.org>
Date: Tue Aug 21 05:46:48 2018

Android: Fix anchor link bug on a new tab

This CL addresses the bug that scrolls to the bottom of the page
opened by anchor in a new tab. The size of the contents should have
been set earlier at |initializeTab|.

This change comes with a risk of reintroducing the regression fixed by
https://crrev.com/c/795479 since it's basically reverting what the CL
did. As of this change, the reported regression is not reproducible,
and it's not easy to find any other sites that exhibit the issue.
The plan is to land this CL and react timely to any problems it might
cause.


Bug:  850868 
Change-Id: Ie4fdbaa012f72a2b667b7b27c177fcc6b7a21032
Reviewed-on: https://chromium-review.googlesource.com/1180637
Reviewed-by: Ted Choc <tedchoc@chromium.org>
Commit-Queue: Jinsuk Kim <jinsukkim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#584662}
[modify] https://crrev.com/b5e60ea4cda5339f48e30480aa1e29a57f1a0f68/chrome/android/java/src/org/chromium/chrome/browser/compositor/CompositorViewHolder.java

Thank you!

Verified fix in Chrome Dev 70.0.3535.2 release. Switching to new tab, displayed content under bolded text.