Assigned
Status Update
No update yet.
Comments
sa...@chromium.org
[Empty comment from Monorail migration]
[Monorail components: Blink>Scroll]
[Monorail components: Blink>Scroll]
sa...@chromium.org
Able to reproduce the issue on reported chrome version #88.0.4324.150 using Mac 10.12, Linux 20.04 and Windows 10 by following steps as per
Reproducible on
==============
90.0.4419.0 - Canary
90.0.4412.3 - Dev
89.0.4389.47-Beta
88.0.4324.150 - Stable
The same issue seems to be reproducible from M75 older versions, hence considering it as Non-Regression and marking it as Untriaged.
Thanks...!!
Reproducible on
==============
90.0.4419.0 - Canary
90.0.4412.3 - Dev
89.0.4389.47-Beta
88.0.4324.150 - Stable
The same issue seems to be reproducible from M75 older versions, hence considering it as Non-Regression and marking it as Untriaged.
Thanks...!!
ke...@chromium.org
[Empty comment from Monorail migration]
gi...@chromium.org
Works in firefox. Breaks in chrome:(
0x...@gmail.com
[Empty comment from Monorail migration]
[Monorail components: Blink>Layout]
[Monorail components: Blink>Layout]
0x...@gmail.com
[Empty comment from Monorail migration]
0x...@gmail.com
+ It has scroll up issue when mouse text drag-selection.
fl...@chromium.org
It looks like the reason this works in firefox is that firefox does not respect the scroll-padding when scrolling inputs you're typing into view:
I actually think that chrome is doing "the right thing" here to spec. We are trying to scroll the sticky element into view, however when we scroll up the sticky element moves up. With fixed position elements we never scroll them into view because scrolling will not shift them, however with sticky position elements there are cases where scrolling is necessary, see
The problem is that sometimes (e.g. in this demo) the reason for the scroll padding is that the sticky element in question is obscuring the top, and we can't really know whether that is the case or not (i.e. it could be a sticky positioned element under a banner). If we naively fix
I actually think that chrome is doing "the right thing" here to spec. We are trying to scroll the sticky element into view, however when we scroll up the sticky element moves up. With fixed position elements we never scroll them into view because scrolling will not shift them, however with sticky position elements there are cases where scrolling is necessary, see
The problem is that sometimes (e.g. in this demo) the reason for the scroll padding is that the sticky element in question is obscuring the top, and we can't really know whether that is the case or not (i.e. it could be a sticky positioned element under a banner). If we naively fix
fl...@chromium.org
FYI I filed
[Deleted User] <[Deleted User]>
I've run into this issue as well, with the (I expect) common use case of having an input inside a sticky header. Chromium browsers consider the header to be outside the scroll-padding-top-ed area and unnecessarily try to scroll to it whenever the input text changes.
Demo:
The workaround for me is going to be to swap the header from sticky to fixed, then have a margin-top of the same height as the header on the following element (probably <main>). It's awkward because it's a hardcoded value, but I'm already using the same hardcoded value for the scroll-padding-top anyway.
Here's a demo of my workaround (with an added <a> to check scroll-padding-top is working correctly too):
Because my position: fixed version works, perhaps the same scroll-related chromium rules need to be applied to position: sticky elements?
Demo:
The workaround for me is going to be to swap the header from sticky to fixed, then have a margin-top of the same height as the header on the following element (probably <main>). It's awkward because it's a hardcoded value, but I'm already using the same hardcoded value for the scroll-padding-top anyway.
Here's a demo of my workaround (with an added <a> to check scroll-padding-top is working correctly too):
Because my position: fixed version works, perhaps the same scroll-related chromium rules need to be applied to position: sticky elements?
gi...@appspot.gserviceaccount.com
The following revision refers to this bug:
commit 6388111d078ecdf3ab858b481ef01ac64dbc815f
Author: Seokho <0xdevssh@gmail.com>
Date: Tue May 04 07:00:37 2021
The sticky positioned element should reset the scroll to an unshifted position by any operation
When the sticky element takes the operation, it keeps the sticky offset to move its position.
However, According to the specification [1], the scroll position should be reset by any operation to that element.
Therefore, pass kIgnoreStickyOffset to AbsoluteToLocalRect() for removing sticky-position offset which is 'unshifted-position'.
[1]
Bug: 664246, 1178622
Change-Id: I7b9e42d1274894a0f3282316a2eb69d0d10c5530
Reviewed-on:
Reviewed-by: Robert Flack <flackr@chromium.org>
Reviewed-by: Mason Freed <masonf@chromium.org>
Commit-Queue: Seokho Song <0xdevssh@gmail.com>
Cr-Commit-Position: refs/heads/master@{#878763}
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[add]
[delete]
[modify]
commit 6388111d078ecdf3ab858b481ef01ac64dbc815f
Author: Seokho <0xdevssh@gmail.com>
Date: Tue May 04 07:00:37 2021
The sticky positioned element should reset the scroll to an unshifted position by any operation
When the sticky element takes the operation, it keeps the sticky offset to move its position.
However, According to the specification [1], the scroll position should be reset by any operation to that element.
Therefore, pass kIgnoreStickyOffset to AbsoluteToLocalRect() for removing sticky-position offset which is 'unshifted-position'.
[1]
Bug: 664246, 1178622
Change-Id: I7b9e42d1274894a0f3282316a2eb69d0d10c5530
Reviewed-on:
Reviewed-by: Robert Flack <flackr@chromium.org>
Reviewed-by: Mason Freed <masonf@chromium.org>
Commit-Queue: Seokho Song <0xdevssh@gmail.com>
Cr-Commit-Position: refs/heads/master@{#878763}
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[add]
[delete]
[modify]
sa...@chromium.org
Tried verifying the fix on latest M92 using repro from
Seokho@ Could you please review the attached screencast and let us know if anything being missed here and help us in verifying the fix.
Thanks..
Seokho@ Could you please review the attached screencast and let us know if anything being missed here and help us in verifying the fix.
Thanks..
0x...@gmail.com
Oh, I see. I guess M92 does not yet contain the patch [1] about this issue.
But the current expectation of this issue is a bit different from the issue reporter's.
According to the spec [2], the sticky positioned element should be initial position with any operation which back to the unshifted position.
And this issue is now tracked with the feature flag 'CSSPositionStickyStaticScrollPosition' which status is 'experimental' (But I guess this flag is not filed yet in Chrome Platform Status) .
So I guess when It becomes 'stable' we could check the issue resolved as above.
[1]
[2]
But the current expectation of this issue is a bit different from the issue reporter's.
According to the spec [2], the sticky positioned element should be initial position with any operation which back to the unshifted position.
And this issue is now tracked with the feature flag 'CSSPositionStickyStaticScrollPosition' which status is 'experimental' (But I guess this flag is not filed yet in Chrome Platform Status) .
So I guess when It becomes 'stable' we could check the issue resolved as above.
[1]
[2]
0x...@gmail.com
[Empty comment from Monorail migration]
ry...@gmail.com
It looks like this bug has gotten worse recently - Version 98.0.4758.82 (Official Build) (64-bit)
Not only does typing in an input box trigger this issue, but focusing on a select element (both by tabbing or clicking). Tabbing to an input element triggers it, but strangely not clicking into an input element.
Not only does typing in an input box trigger this issue, but focusing on a select element (both by tabbing or clicking). Tabbing to an input element triggers it, but strangely not clicking into an input element.
fl...@chromium.org
[Empty comment from Monorail migration]
gi...@appspot.gserviceaccount.com
The following revision refers to this bug:
commit 7f1e3f5ea871baa715c549a55e78f43327e46e9b
Author: Robert Flack <flackr@chromium.org>
Date: Fri Oct 21 16:13:28 2022
Switch CSSPositionStickyStaticScrollPosition to test status
The spec change to scroll sticky position elements to their non-shifted
position is causing surprising breaking behavior on existing content.
Let's move this feature to test status until we resolve the working
group issue.
Bug: 1178622, 1334207
Change-Id: I04e6895b8040c331385302f18fc3200c504fef03
Reviewed-on:
Commit-Queue: Vladimir Levin <vmpstr@chromium.org>
Reviewed-by: Vladimir Levin <vmpstr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1062168}
[modify]
commit 7f1e3f5ea871baa715c549a55e78f43327e46e9b
Author: Robert Flack <flackr@chromium.org>
Date: Fri Oct 21 16:13:28 2022
Switch CSSPositionStickyStaticScrollPosition to test status
The spec change to scroll sticky position elements to their non-shifted
position is causing surprising breaking behavior on existing content.
Let's move this feature to test status until we resolve the working
group issue.
Bug: 1178622, 1334207
Change-Id: I04e6895b8040c331385302f18fc3200c504fef03
Reviewed-on:
Commit-Queue: Vladimir Levin <vmpstr@chromium.org>
Reviewed-by: Vladimir Levin <vmpstr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1062168}
[modify]
ha...@google.com
[Empty comment from Monorail migration]
fl...@chromium.org
FYI I've filed
is...@google.com
This issue was migrated from
[Multiple monorail components: Blink>Layout, Blink>Scroll]
[Monorail mergedwith:
[Monorail components added to Component Tags custom field.]
[Multiple monorail components: Blink>Layout, Blink>Scroll]
[Monorail mergedwith:
[Monorail components added to Component Tags custom field.]
ch...@google.com
The Found In field may only contain full version values (e.g., 109.0.9878.12). Some values couldn't be corrected but were removed, please verify that any important data wasn't lost. You can see the changes by toggling full history on the issue.
Description
Chrome Version : 88.0.4324.150
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL, along with the version, after other browsers where you
have tested this issue:
Safari: OK
Firefox: OK
Edge: Fail 88.0.705.68
What steps will reproduce the problem?
(1) open the a.html in attach
(2) scroll to the bottom of the div
(3) type any thin in the input box
What is the expected result?
no scroll
What happens instead?
the div scroll automatic
Please provide any additional information below. Attach a screenshot if
possible.
See
See also related spec proposal to make it easier to author sites that declare whether their sticky content should be part of the scroll padding or not: