I'm confused by the "Web Inspector" prefix. Does this happen in Web Inspector, or does it happen in normal web pages?

Updated the bug title.

<rdar://problem/117528549>

FYI, it's a sample code to explain this issue. - https://jsfiddle.net/cqzv37nm/4/

Created attachment 469114 [details] Test case

What's happening here is that we reveal the element inside the overflow scroll, and then also scroll the overflow scroller itself to the top of the view, which isn't necessary if it's fully visible. I'll do some testing to see how other browsers behave.

The attached test case has identical behavior in Chrome, Firefox and Safari.

Created attachment 469118 [details] Test case with { behavior: 'smooth', block: 'start' }

I don't have enough information to fix this bug at this point. Please attach a test case that has different behavior in Chrome and Safari.

Created attachment 469120 [details] Issue Repro Steps

@Simon, thank you for taking time to look at this issue. I may not clearly describe the repro sequences with the test URL. I tried with both of the test cases you attached today and I could easily repro the issue. Please review the attached video capture. To reproduce the issue, click the list and then go to the top of the list and move back and forth afterwards.

It looks like you're using a wheel mouse rather than a trackpad, and you're using the mouse wheel while hovered over the scrollbar, is that correct? I'm not sure how this is related to the JS calling scrollIntoView(). Perhaps you're describing a different bug from the original report.

@Simon, that is right. I used mouse wheel event while hovered over the scrollbar. I believe we raised the issue for the mouse wheel event as we refer to the stack overflow discussion <https://stackoverflow.com/a/52835382>. But please let me know which parts of bug report may not described incorrectly.

Does your issue reproduce in a test case that never calls scrollIntoView()?

@Simon, thank you for the detailed information. Will double check again.

@Simon, I just checked it again without scrollIntoView call and see the same behavior. So, the issue I reproduce is not related to the scrollIntoView. Sorry about the confusion. However, I can also confirm that the original issue reported by Hanoor still related with the scrollIntoView(block: 'start') since it has been fixed by having (block: 'nearest', inline: 'start') options and it is only needed on the Safari Browser. So, I will share more clear repro sequences once we will find a test case for this.

Created attachment 469177 [details] Invisible area introduced by iframe

Created attachment 469178 [details] Test case with iframe with { behavior: 'smooth', block: 'start' }

@Simon, I could find the issue only happening when there is invisible area as attached image <invisible area introduced by iframe>. Please try with new test case with iframe. When you click the menu item, you can see the page will be moved up by 20px which is same height introduced by the iframe.

Thank you for the new test case. I can reproduce.

What's happening in your test case is that you end up with two iframes below the 100% height content, making the content scrollable, so clicking on a section tries to scroll as much as it can (20px or so). Still, there's a bug with `block: start`

@simon, thanks for the review the issue. I think we can work around the issue by setting the the iframe to display:block instead of display:inline. Would it be acceptable workaround based on the current test case since we do not want the iframe be shown on the page?

https://bugs.webkit.org/attachment.cgi?id=469178 scrolls in Chrome too, but not Firefox.

Each iframe adds 20px of scrollable overflow because of `line-height: 20px;`. You should also stop using `overflow: overlay` since this is just a synonym for `overflow: auto` (but this doesn't change behavior). Safari and Chrome have the same behavior here, so I think there's no bug here.

@simon, thanks for taking time to investigate it and confirmation.