- From: Michal Zalewski <lcamtuf@coredump.cx>
- Date: Fri, 21 Jan 2011 09:25:29 -0800
- To: gaz Heyes <gazheyes@gmail.com>
- Cc: Giorgio Maone <g.maone@informaction.com>, Daniel Veditz <dveditz@mozilla.com>, Brandon Sterne <bsterne@mozilla.com>, public-web-security@w3.org, Lucas Adamski <ladamski@mozilla.com>
>> Also, what if a frame is moved underneath the cursor just milliseconds >> before the user clicks something - in which case, the tooltip appears >> too late to allow for any meaningful reaction? > > JavaScript should not be able to control of iframes that have been allowed > with x-frame-options. That does not solve the problem; a frame can be repositioned by moving around a <div> that contains it, or deleting / adding elements before it. The ability to control page layout from JS level to this extent appears to be essential to how the Internet works today. >> What if the document is larger than window size? Can the frame be >> rendered partly off-screen, so that only several pixes are still left >> on the screen? > > The iframe shouldn't be rendered in any way off screen, it should either be > centered or removed from display. Keep in mind that this is a legitimate scenario; you can have a page that is longer than window size, and has a scroll bar. From that perspective, the first option is unacceptable: you don't want all "like" buttons on a three-page document to appear out of place as you scroll. The latter is perhaps possible, but causes flicker when you scroll. >> I can also imagine this colliding in nasty ways with things such as >> drop-down lists or menus - you don't want "like" buttons to be drawn >> on top of them :-( > > It's up to the dev to place the iframe in a place were it doesn't overlap, > the iframe should always be higher than any other element IMO. Again, consider non-malicious uses: let's say I'm on Flickr or Youtube, and there is a drop-down menu with a list possible actions, then "like"-able comments several hundred pixels below. I don't think it's a very bad proposal, but it immediately runs into a number of problems that are difficult to seamlessly account for, which is why I haven't proposed it back in 2008 - opting for blocking input to partly obstructed frames, instead. Even that got panned on complexity and usability grounds; some of that criticism is knee-jerk, but some is very much valid ;-) Cheers, /mz
Received on Friday, 21 January 2011 17:26:22 UTC