[Bug 28488] An element might not have a window to call scrollY on


Simon Pieters <simonp@opera.com> changed:

           What    |Removed                     |Added
                 CC|                            |annevk@annevk.nl,
                   |                            |ian@hixie.ch

--- Comment #3 from Simon Pieters <simonp@opera.com> ---
(In reply to Boris Zbarsky from comment #2)
> I don't think that's reasonable, for several reasons:
> 1)  It's ambiguous about whether the canonical defaultView getter is invoked
> or whether the current defaultView value is gotten.  The latter may have
> been munged by JS.  This needs to be clarified somehow (and this is a
> general problem in specs, really...).

When a method or an attribute is said to call another method or attribute, the
user agent must invoke its internal API for that attribute or method so that
e.g. the author can’t change the behavior by overriding attributes or methods
with custom properties or functions in ECMAScript.

I plan to fix this overall in CSSOM but for now the above paragraph will have
to do.

> 2)  If the node document is not the active document in its browsing context,
> the defaultView will still return, per spec "the Document's browsing
> context's WindowProxy object".  So as the spec is written right now, you
> could grab an element from a document, navigate the browsing context, then
> set scrollTop on that element to scroll the new document in the browsing
> context or get scrollTop to get its scroll position .  That's clearly
> undesirable.  So you need to bail out if the node document is not the
> current document in the browsing context if you want to use the defaultView
> (but see below).

OK. Good point. Fixed:


> 3)  The various accesses on the windowproxy (scrollY, etc) have a problem
> similar to #1.
> #2 is critical to solve.  Ideally we would solve it by just getting the
> Document's current Window, but I see nothing obvious in the HTML spec that
> defines such a concept.  Failing that, we can make do with a check for being
> the active document and then working with the windowproxy.  But that might
> actually give different behavior in cases when a presentation is cached
> (e.g. operating directly on a window might allow scrolling a cached
> presentation while operating on the windowproxy but restricting to the
> active document case makes attempts to do so no-op).  So we should decide
> what we actually want here for that case.

How would you operate directly on a window? Don't you only have access to the
WindowProxy, so scrolling operations will always scroll the active document?

I'm happy to use a hook instead of document.defaultView here if one is provided
in HTML.

> For #1 and #3 if there's a simple fix of some sort that would be great;
> might want to check with Anne whether there's an existing convention for it.

I think Anne's convension is to define concept-foo and then have the API call
concept-foo instead of calling another API.

You are receiving this mail because:
You are the QA Contact for the bug.

Received on Friday, 17 April 2015 07:28:44 UTC