core(gather-runner): always reset scroll position #9060
Conversation
| * @return {Promise<{x: number, y: number}>} | ||
| */ | ||
| getScrollPosition() { | ||
| return this.evaluateAsync(`({x: window.scrollX, y: window.scrollY})`, {useIsolation: true}); |
There was a problem hiding this comment.
feels like the protocol should have something for this...Page.getLayoutMetrics?
There was a problem hiding this comment.
not that I can find
There was a problem hiding this comment.
looks like it's Page.getLayoutMetrics -> response.visualViewport.pageX and pageY, but it's possible in the end that it's worse perf than this evaluateAsync
| */ | ||
| scrollTo(position) { | ||
| const scrollExpression = `window.scrollTo(${position.x}, ${position.y})`; | ||
| return this.evaluateAsync(scrollExpression, {useIsolation: true}); |
There was a problem hiding this comment.
feels like the protocol should have somethign for this too, but I don't see anything
There was a problem hiding this comment.
You can synthesize a gesture but that's not what we want to do https://chromedevtools.github.io/devtools-protocol/tot/Input/#method-synthesizeScrollGesture
There was a problem hiding this comment.
You can synthesize a gesture but that's not what we want to do
yeah, I meant it feels like there should be a method :)
There was a problem hiding this comment.
apparently this is exactly what devtools does (e.g. "Scroll into view" in the devtools panel just remote evals scrollIntoViewIfNeeded(true) on the selected element) so we're in good company :)
| return await this._evaluateInContext(expression, contextId); | ||
| } catch (err) { | ||
| // If we were using isolation and the context disappeared on us, retry one more time. | ||
| if (contextId && err.message.includes('Cannot find context')) { |
There was a problem hiding this comment.
is this still needed given the new event handling?
There was a problem hiding this comment.
I'm not sure what you mean by new event handling, but it's something we should do regardless. Our temporary context can be destroyed at any time and we used to see high volumes of this in sentry once upon a time.
There was a problem hiding this comment.
Oh do you just mean Runtime.executionContextDestroyed? It can still race if we're trying to eval this between when we receive the context destroyed event and we eval this, plus the aforementioned destroying of our context regardless of navigation :)
There was a problem hiding this comment.
Oh do you just mean Runtime.executionContextDestroyed? It can still race
yeah, I guess it feels like we should be handling it the "correct way"™ or the "sloppily but effectively prevent race conditions way", but not both, but w/e :)
Reland of #8625 (reverted in #9059)