Bug 85884
Summary: | REGRESSION: Scrollbar in wrong position for element that is hidden then unhidden | ||
---|---|---|---|
Product: | WebKit | Reporter: | dubroy |
Component: | Layout and Rendering | Assignee: | SravanKumar S(:sravan) <ssandela> |
Status: | RESOLVED CONFIGURATION CHANGED | ||
Severity: | Normal | CC: | ahmad.saleem792, ap, darin, mrahaman, rniwa, ssandela, webkit-bug-importer, zalan |
Priority: | P2 | Keywords: | InRadar |
Version: | 528+ (Nightly build) | ||
Hardware: | All | ||
OS: | All |
dubroy
When an element that has 'overflow: auto' is hidden and then shown again, the scrollbar is rendered at its old position, but it behaves as though it's at the top. I.e., it's only possible to scroll down, not up.
Repro case:
<!doctype html>
<title></title>
<div style="height: 100px; overflow: auto; border: 1px solid pink;">
<div style="height: 200px;"></div>
</div>
<script>
function toggleVisibility() {
var div = document.querySelector('div');
// div.style.display = (div.style.display == 'none') ? 'block' : 'none';
div.hidden = !div.hidden;
}
document.onclick = function() {
toggleVisibility();
setTimeout(toggleVisibility, 0);
}
</script>
To reproduce:
1. Scroll down to the bottom of the outer div.
2. Click somewhere outside the div to hide and re-show it.
3. Observe that even though the scroll bar appears to be at the bottom, it's not possible to scroll up. Scrolling down causes the scroll bar to jump to the top, then everything works as expected.
I've observed this in the WebKit nightly build, and in Chrome Canary (20.0.1130.0) and Dev (20.0.1123.4). The bug is not present in Safari 5.1.5 (6534.55.3) or Chrome 19.0.1084.41.
This looks related to bug 47963 and bug 26438 but it's not quite the same issue.
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
Alexey Proskuryakov
Does this affect any live web sites?
dubroy
Not that I know of. It affects some code on the Chrome new tab page though.
SravanKumar S(:sravan)
I think this is happening because, hide and un-hide mouse events are calling Scrollbar Destructor and Constructor. But while re-constructing, m_currentPos of scrollbar class is not being retained or previous state is lost.
SravanKumar S(:sravan)
This bug is fixed in the latest code. I tried to see if this is a duplicate of some other bug, but no such patch from 8th of this month. There are other scrollbar related patches, i think they should have fixed this.
But not sure if we can close this as the bug might re-appear.
Can some once comment, on its resolution state?
Ahmad Saleem
Based on Comment 01 test case, I am not able to reproduce this behavior of "scrollbar" getting stuck at bottom and not scrolling up in Safari 15.5 on macOS 12.4.
Even Comment 04 mentioned that it was fixed right after it was reported due to some other fixes.
Can this be marked as "RESOLVED INVALID" or "RESOLVED CONFIGURATION CHANGED"? Thanks!
Radar WebKit Bug Importer
<rdar://problem/95610036>