Issue metadata
Sign in to add a comment
|
Iframe should not be able to scroll the parent
Reported by
uudrui...@gmail.com,
Jan 18 2017
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36 Steps to reproduce the problem: I'm playing with shellinabox, and while I agree many of its methods are draconic or otherwise hackish, I think there is point to be made that odd corner cases can show bugs that are otherwise hard to find. Shellinabox uses an input field which is keeps focused to record keystrokes. This must not be display:none nor interfere with the page in any way, so it is set to an absolute position of -10000px (both top and left) so that it is offscreen. Now, place the system into an iframe that displays completely "below the fold" (below the bottom of the screen so you have to scroll to it) and as soon as the iframe gets focused, the input gets focus. Chrome now scrolls the parent document all the way to the top of the page. However, this makes no sense because the input field is in the iframe, not the parent. What is the expected behavior? I would expect that the only thing that should scroll (if scrollable at all), would be the iframe itself. Nothing that happens with the iframe's "jail" should propogate to the parent. In this case, Chrome's behavior is scrolling the page to the top and taking the input field (in the iframe below the fold) OUT of view ... the exact opposite of its design. What went wrong? If Chrome attempts to scroll the parent page in any way, it needs to crop the given coordinates to the bounds of the iframe. Right now, it looks like it may be subtracting the 10000 pixels from the iframe's position and attempting to scroll 10000 pixels above the iframe. A simple bounds check to confine coordinates to the iframe itself would maintain sanity, likely not just in this instance, but possibly other cases as well. It just seems like the right thing to do (at least to me). Did this work before? No Chrome version: 53.0.2785.143 Channel: n/a OS Version: Flash Version: Shockwave Flash 24.0 r0 I have a work-around in shellinabox (my version anyway), but I wonder people seeing Issue #437025 might be actually be seeing a variation of this instead.
,
Jan 18 2017
Thanks for filing the issue. Could you please provide a sample HTML file to reproduce the issue from test team end.
,
Jan 18 2017
Demonstrating would require 2 .. parent and child. To test, scroll down to the iframe, click it. When it focuses the inner/hidden input, the whole page will scroll to the top (I'm thinking its the negative offset of the input field).
Outer/Parent ...
<!DOCTYPE html>
<html lang="en">
<head>
<title>shellinabox iFrame click test</title>
</head>
<body>
<div id="spacer" style="height: 100vh; width=80%;">Spacer</div>
<iframe id="shellinabox" src="inner.html" style="width: 800px; height: 400px;">
</iframe>
</body>
</html>
Then the inner.html ...
<!DOCTYPE html>
<html lang="en">
<head>
<title>Inner Frame</title>
<style>
.hidden {
position: absolute;
top: -10000px;
}
</style>
</head>
<body>
<input id="input" class="hidden" type="text" />
<div id="junk" style="height: 50vh; width=80%;">This is random - click it</div>
<script>
document.getElementById("junk").onclick = function() {
document.getElementById("input").focus();
};
</script>
</body>
</html>
,
Jan 19 2017
Unfortunately, iFrames are not quite the behavior "jail" as they might seem - especially for iframes that are from the same origin. focus() and scrollIntoView in particular scroll the Element into view recursively, so scrolling the main frame is expected. The idea to mask the Element to the iframe bounds sounds logical - in fact we tried it to fix issue 437025 . But this ended up causing issue 673396 so we had to relax that rule. Unfortunately, there's no spec or agreement on how these kinds of edge cases should work. Absent that, we've been trying to match what other browsers do. How does Firefox behave on your example?
,
Jan 26 2017
,
Jan 26 2017
Firefox behaves the same. In fact, this has been an open issue in shellinabox for a long time, and people pointed to isse 437025 and others instead of patching it. Personally, I would think that it should scroll for the case of hidden elements in a DIV, since the element is on the page being scrolled. In the case of an Iframe, the element shouldn't even be looked at. When the focus hits "something in the Iframe" it could possibly scroll the iframe into view, but not mess with the actual contents ... more of a jail. I understand this may be difficult or inefficient to implement in the current code base, and not likely to matter much except in strange corner cases. In this instance (idea taken from issue 673396 ), it looks like hidding an input field with overflow:hidden and maybe 0 width and height will still allow it to take input (display:none I'm guessing would not be focusable). This means I can change the code above and keep the input field local instead of the original code that placed it off-screen. This would have the side-effect of scrolling the Iframe into view rather than scrolling it out of view, so ... I can get the expected behavior in the current code by working around it (untested, but knowing whats going on, I'm pretty sure it will work). At the moment, in case someone else is having a similar issue. I am using element.select() rather than element.focus() which seems to stop the field from scrolling but still moves the input focus. I'll be changing this soon so as not to rely on undocumented behavior.
,
Feb 9 2017
If our behavior matches Firefox than I don't think we want to make any changes. While a more "sane" behavior might be nice, there's potential compat impact in that we might break existing pages by making a change. In the absence of a compelling reason and given that you seem to have a workaround I'm going to close this as WontFix. Thanks for filing. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by hdodda@chromium.org
, Jan 18 2017