Issue metadata
Sign in to add a comment
|
inconsistent mousewheel and keyboard scroll for iframes once hidden and shown again
Reported by
dmice...@1ps.ru,
Dec 30 2016
|
||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36 Steps to reproduce the problem: 1. Open attached mwtest.html with chromium. It contains two iframes with content of mwtest_content.html. One iframe is visible while another have display:none 2. Scroll down in iframe with mouse wheel or with keyboard. Bring content to the middle to make it more obvious. Scrolling with mouse wheel would be more informative because I set handler for it to display current scroll position. 3. Switch to another iframe with "Show 2" link. It will set display:none on first iframe and show another. 4. Scroll down in second iframe. 5. Switch back to first iframe with "Show 1" link. Content of iframe would be scrolled right in place it was left before hide. 6. Click inside iframe to be sure scroll focus is in place. 7. Scroll with mouse wheel or with keyboard just once. What is the expected behavior? Previous scroll position remain. What went wrong? Content jump to the top. Did this work before? Yes Users told me it worked somewhere in September Does this work in other browsers? N/A Chrome version: 55.0.2883.87 Channel: stable OS Version: Flash Version: Firefox just drop scroll position on iframe show. But! With FF it is possible to easily restore scroll position on show with scrollTo() method. For chrome it does not work at all: scrollTo() executes, scrollY show nothing wrong, but content still jumps to the top on mousewheel event. If you look carefully at the scrollY indicator in my test, you will see what after first wheel event scrollY increases relative to the previous scroll position, while content already jump to the top. That is why I think there is some inconsistency between different scroll position indicators inside chrome.
,
Jan 4 2017
,
Jan 4 2017
Tested on Ubuntu 14.04 using chrome M55 #55.0.2883.87 and no inconsistence is seen on scrolling in iframes. Attached screencast for reference. @dmiceman-- Could you please check the attached screencast and let us know if we have missed out anything in reproducing the issue. Thanks!
,
Jan 4 2017
First, you did not scroll after iframe change :-) Second is my fault — test files was intended to be run from some http server to mitigate cross-domain dom access restrictions. Please try updated files, uses postMessage() instead of direct dom access. Third, I have made more testing: 1. Chrome on windows, 55.0.2883.87 m (64-bit): does not have the problem! But I still believe what some windows version is affected. Unfortunately, can't tell more till January 10. 2. Chromium Version 55.0.2883.87 Built on Ubuntu , running on Ubuntu 16.04 (64-bit): affected! Please look at my screencast.
,
Jan 4 2017
Dont know what is wrong with my screencast. Vlc (and only vlc) play it well. Will try to supply recordmydesktop with right options.
,
Jan 6 2017
Tested on ubuntu 14.04 desktop using chrome stable M55 #55.0.2883.87 and issue is reproduced. Issue is seem from M51 and from M40 to M50 ,the issue behavior is different or the given test files are not loaded completely. Note : Issue is not seen on ubuntu 14.04 laptop and windows 10 . Marking it as untriaged , so that someone would address this. Thanks!
,
Jan 12 2017
sungunjia@ I can certainly reproduce this when I switch the iframes and focus the item and use keyboard down scrolling. Seems to work fine if I do a compositor scroll (wheel) first and then use keyboard scrolling. Seems closely related to scroll into view so assigning to you.
,
Jan 17
(6 days ago)
|
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by dmice...@1ps.ru
, Dec 30 2016