Intersection Observer not firing when root is body and element is position: fixed |
||||||
Issue descriptionVersion: 55.0.2880.4 OS: Windows 7 Test page: https://bayden.com/test/intersection/rootisbody.html This page has two intersection observers, one of which specifies document.body as the root and the other specifies no root (so Viewport should be used). Observe: Visibility changes ARE NOT fired for the [Observer root=body] for position:fixed or position:absolute elements when element visibility is toggled. The [Observer root=viewport] does raise events (so long as the element is within the viewport). Context: For a Chrome feature, we need to be able detect when a given element is unhidden, even if it is outside of the current viewport.
,
Oct 6 2016
,
Oct 10 2016
Friendly ping to szager and ojan: can either of you confirm that this is not WAI? Also, if not WAI, this'll block a high-priority project for us ( issue 647754 ) so I'd be happy to take a look into fixing myself but would probably need a couple pointers as to where to start.
,
Oct 10 2016
,
Oct 10 2016
The problem here is that document.body is not a fixed-position container, so it's not in the containing block chain of the target element when it has fixed or absolute position. So, yes: it is WAI. If you want to track the visibility of a target outside the document viewport, MutationObserver might be a better fit.
,
Oct 10 2016
Thanks, szager. We thought about using MutationObserver but concluded it wouldn't quite work for our purposes. For example, imagine a password input is invisible, but then a dynamically added stylesheet sets all password inputs to visible. We played around with that case and found that MutationObserver didn't fire because the element wasn't mutated itself. Are there any other directions you can think of that we should explore?
,
Oct 10 2016
I suppose you could add something to the 'hidden' attribute setter in the DOM bindings.
,
Oct 11 2016
I don't think a MutationObserver is a reasonable solution here, but I agree that this seems to be working as intended. I'll close the bug for now. estark: maybe the three of us should meet up to discuss your use case?
,
Oct 11 2016
esprehn and I chatted about it some more yesterday and concluded that maybe we don't actually need any kind of observer at all for our use case, and that instead we can just trigger the warning from PasswordInputType::createLayoutObject(). That's what I've implemented in the latest iteration of https://codereview.chromium.org/2378503002. If that turns out to not work for some reason, then meeting up to discuss alternatives would probably be good. I'll let you know if that's necessary. Thanks szager esprehn and ojan for all your help as we figure this out!! |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by est...@chromium.org
, Oct 5 2016