iFrame Custom Styled Scrollbar Disapears After Updating iFrame content
Reported by
mattbier...@gmail.com,
Jan 5 2017
|
|||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.98 Safari/537.36 Example URL: Steps to reproduce the problem: See attached document for full repo. 1. Create iFrame that uses `::-webkit-scrollbar` with a large page of content so that a scrollbar is shown 2. Update the iFrame's content using `contentDocument.write` 3. What is the expected behavior? Scrollbar remains visible What went wrong? Scrollbar disapears Does it occur on multiple sites: N/A Is it a problem with a plugin? N/A Did this work before? N/A Does this work in other browsers? N/A Chrome version: 54.0.2840.98 Channel: n/a OS Version: OS X 10.11.6 Flash Version: Shockwave Flash 24.0 r0 Discovered in VSCode by https://github.com/Microsoft/vscode/issues/17617 If anyone has any thoughts on working around this issue, please let me know. I've tried setting the overflow style and the scrolling attribute of the iframe, but neither fixes the issue
,
Jan 6 2017
Unable to reproduce the issue in Mac 10.12.2, Win-10 and Ubuntu 14.04 by using chrome reported version #54.0.2840.98 and latest canary #57.0.2973.0. Steps followed to reproduce the issue are as follows: ----------- 1. Downloaded the attached iframe.html file. 2. Opened that file in the chrome browser. 3. Observed that scrollbar remained visible as expected. Attaching screen cast for reference mattbierner@ - Could you please check this issue on latest canary #57.0.2973.0 by creating a new profile without any apps and extensions and please let us know if the issue still persist or not. Thanks...!!
,
Jan 6 2017
Thank you for looking into this. Sorry I didn't clairify one point about the bug: it only seems to happen after the first iFrame update (and not 100% of the time). In the demo, can you try clicking the button multiple times. This will recreate the iFrame content and should reproduce the problem.
,
Jan 9 2017
Able to reproduce this issue on Mac 10.12.2, Win-10 and Ubuntu 14.04 using chrome reported version #54.0.2840.98 and latest canary #57.0.2976.0. This is a non-regression issue as it is observed from M30 old builds. Hence, marking it as untriaged to get more inputs from dev team. Thanks...!!
,
Jan 9 2017
,
Jan 10 2017
,
Jan 13 2017
,
Jan 19 2017
skobes@, eae@ here is a scrollbar presence issue that is reported against vscode not sure if one of you can look into it but probably has some importance to fix.
,
Jan 19 2017
Possible dupe: https://bugs.chromium.org/p/chromium/issues/detail?id=641881
,
Jan 25 2017
As a workaround, write an empty document into the iframe before replacing the contents.
target.contentDocument.open();
target.contentDocument.close();
target.contentDocument.open('text/html', 'replace');
// ...
,
Jan 26 2017
Thanks for taking a look. We were able to work around this issue on the VSCode side
,
Jan 26 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/2b2839b3fba03dab76bee97c6aa4eb1ab1ecb836 commit 2b2839b3fba03dab76bee97c6aa4eb1ab1ecb836 Author: skobes <skobes@chromium.org> Date: Thu Jan 26 17:27:46 2017 Handle stale m_owner in FrameView::needsScrollbarReconstruction. If iframe content is replaced by document.write, its LayoutScrollbar can hold a reference to the previous body element. FrameView now detects this situation and reconstructs the scrollbar. This mirrors similar code in PaintLayerScrollableArea added in r352644. BUG= 678821 Review-Url: https://codereview.chromium.org/2657743004 Cr-Commit-Position: refs/heads/master@{#446360} [add] https://crrev.com/2b2839b3fba03dab76bee97c6aa4eb1ab1ecb836/third_party/WebKit/LayoutTests/scrollbars/custom-scrollbar-reconstruction-document-write.html [modify] https://crrev.com/2b2839b3fba03dab76bee97c6aa4eb1ab1ecb836/third_party/WebKit/Source/core/frame/FrameView.cpp [modify] https://crrev.com/2b2839b3fba03dab76bee97c6aa4eb1ab1ecb836/third_party/WebKit/Source/core/frame/FrameView.h
,
Jan 27 2017
Verified in canary (58.0.2994.1). |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by ligim...@chromium.org
, Jan 6 2017