Bisect info: 549505 (good) - 549514 (bad)
https://chromium.googlesource.com/chromium/src/+log/fa01f1ef..0bd16722?pretty=fuller
Suspecting r549511 = 348d23ce26e25195a70f0be40f88d72b8fad0955 = https://crrev.com/c/955544 by adithyas@chromium.org
"Skip layout if possible in Element.focus"
Landed in 67.0.3394.0

P.S. Attaching a simplified test.html: 1. click the selector, 2. observe

Deleted: test.html 397 bytes

test.html 397 bytes View Download

This was fixed by https://crrev.com/c/1089042.

> This was fixed by https://crrev.com/c/1089042.

This is still reproducible with 69.0.3460.0 canary.

Ahh sorry, I was testing it with an older patchset in the CL. This is definitely related to the UpdateLayout call in SetFocusedElement, removing it from there fixes this.

Still happens in 69.0.3462.0 canary.

Seems like having the UpdateStyleAndLayout here (https://chromium.googlesource.com/chromium/src/+/master/third_party/blink/renderer/core/dom/document.cc#4653) changes the result of BoundingBoxForScrollIntoView for the select element from (8, 0) to (8, -766), which is causing the scroll I think. I'm not really sure why, any ideas bokan@?

Looks like the scroll position is incorrectly accounted for in the layout. I'll take a closer look tomorrow.

I'll be OOO for a few weeks so assigning to chaopeng@ to take a look 

I have do some investigation:

1. It calls focus twice.
  1) from HTMLSelectElement::MenuListDefaultEventHandler, focus to <select>
  2) from V8HTMLElement::focusMethod, focus to <select><option>
  Scroll to top happens in the second one.
2. I also see the BoundingBoxForScrollIntoView changed after UpdateStyleAndLayoutIgnorePendingStylesheetsForNode[1] in Document::SetFocusedElement: "0,0 30.4063x333.875" -> "0,0 47x36"

[1] https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/dom/document.cc?rcl=7a5feed58d4c2e2e8870d1dbd9e05e61039b9d27&l=4591

Assign to sunyunjia@. She may know this since it is related to ScrollIntoView.

Dug into this a bit, it's caused by LayoutObject::AbsoluteBoundingBoxRectForScrollIntoView for the select dropdown returning the wrong value. When the page is scrolled down and we ask for its absolute bounding box location, the value we get is (0px, -4848px) (for e.g.). This is wrong because the select is sticky and appears at the top of the viewport so it's absolute bounding box should be ~(0px, 0px).

It looks like the fault is in LayoutBox::MapLocalToAncestor. There we have:

bool is_fixed_pos = Style()->GetPosition() == EPosition::kFixed;
if (CanContainFixedPositionObjects() && !is_fixed_pos)
    mode &= ~kIsFixed;
  else if (is_fixed_pos)
    mode |= kIsFixed;

And sure enough, switching to position: fixed doesn't have the same issue. Presumably we should be checking for sticky and doing something similar.

flackr@, how do we correctly handle scroll-offset for sticky objects? 

ping, flackr@ - do you know how we should do this?

This sounds like another bug similar to several that Stephen has worked on fixing. As sticky constraints are updated during the compositing inputs / prepaint walk, we can't correctly calculate sticky position until that is clean. Stephen added Document::EnsurePaintLocationDataValidForNode for this purpose which is called when we require a node have correct paint location. You may be able to resolve by ensuring that this is called.

In general, these issues would be fixed by issue 752095 except that we haven't had time to prioritize it, but my understanding is that layoutng is going to aim to move sticky constraint calculation.

This bug still exists in the latest stable chrome Version 69.0.3497.100 (Official Build) (64-bit).

Seems like a real solution will require fixing issue 752095. In the mean time, adithyas@, could you look into mitigating the issue for sticky Elements since this is a regression?

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

commit e1aa11528e75bad7d7676d44970338a8e1c12a6b
Author: Adithya Srinivasan <adithyas@chromium.org>
Date: Wed Sep 19 16:42:14 2018

Fix focus for sticky elements

As per discussion in the associated bug, we call
EnsurePaintLocationDataValidForNode, which ensures that the document
lifecycle is advanced to kCompositingInputsClean for sticky elements in
order to correctly calculate its position.

Bug:  850380 
Change-Id: I27665028393cee6f330fda747b4a344e994fe8fe
Reviewed-on: https://chromium-review.googlesource.com/1231378
Reviewed-by: Kent Tamura <tkent@chromium.org>
Commit-Queue: Adithya Srinivasan <adithyas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#592440}
[add] https://crrev.com/e1aa11528e75bad7d7676d44970338a8e1c12a6b/third_party/WebKit/LayoutTests/fast/css/sticky/sticky-focus-after-scroll.html
[modify] https://crrev.com/e1aa11528e75bad7d7676d44970338a8e1c12a6b/third_party/blink/renderer/core/dom/document.cc

I checked Chrome Canary 71.0.3557.0 and the bug is fixed. 
Thanks a lot!

 Issue 908898  has been merged into this issue.

 Issue 910052  has been merged into this issue.