[whatwg] cross-domain scrollIntoView on frames and iframes

[Ian Hickson]

On Mon, 29 Jun 2009, Ojan Vafai wrote:
> On Tue, Jun 2, 2009 at 11:38 PM, Ian Hickson <ian at hixie.ch> wrote:
> > On Fri, 3 Apr 2009, Ojan Vafai wrote:
> > >
> > > I'm suggesting an addition to cross-domain (i)frames that allows 
> > > scrolling specific content into view. The use case is sites that 
> > > aggregate data from many sites (e.g. search engines) and want to 
> > > display that data in an iframe. They can load the page in an iframe, 
> > > but they have no way to make the content visible as they don't have 
> > > access to the iframe's contents.
> > >
> > > A few possible APIs come to mind. I personally prefer the 
> > > javascripty option below, but I'll include another one for good 
> > > measure.
> > >
> > > 1) Add a scrollPathIntoView (with a better name) on iframes that 
> > > takes either an xpath or a css selector and scrolls the specified 
> > > item into view. If no such item exists, it does nothing. If one or 
> > > more such items exist, it calls scrollIntoView on the first matching 
> > > item.
> > >
> > > 2) Add a css or xpath expression to fragment identifiers. Tthe 
> > > iframe src can be set to http://foo.com#css(.foo 
> > > <http://foo.com/#css(.foo> #bar). Same as above applies. If there's 
> > > no match, it's a noop. If there is a match, it scrolls the first one 
> > > into view.
> > >
> > > In both cases, no explicit success or failure is returned to the 
> > > caller as that would leak the iframes DOM across domains.
> > >
> > > This API can obviously be supported on same-domain iframes as well, 
> > > but it's not really necessary since you can just dig into the DOM of 
> > > the iframe.
> >
> > On Mon, 6 Apr 2009, Jonas Sicking wrote:
> > >
> > > From my point of view I'm not sure how interesting this whole 
> > > feature is. We had support in firefox for XPointer for many years 
> > > and saw little to no uptake. I'm not sure if anyone complained when 
> > > we removed the support even (which would be pretty remarkable).
> >
> > It seems that with such an API and with some careful timing 
> > measurements, you could determine the contents of a foreign iframe. 
> > I'm not sure that's a good idea.
> 
> Can you expand on what you mean a bit? I'd like to see if there's still 
> a way we can meet the use-case.

Suppose that there is a tool where someone can write some text, in which 
case the text will be displayed when the page is loaded. Suppose that 
whether the person has written this text is confidential, and that whether 
one had entered text there or not would reveal something that the user 
would prefer to keep secret.

You could use this API to tell whether or not another user had entered 
text, by opening an iframe to that page, and then trying to scroll from 
distance n to distance n+10 many times in a loop, and timing how long it 
takes to do the scroll. If there is no more content in the page, then 
scrolling to n and n+10 would take less time than it would if there was 
more content (since scrolling is slower than doing nothing).

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'