mirror of
https://github.com/mozilla/gecko-dev.git
synced 2024-10-22 09:45:41 +00:00
7fb92b8c44
The VisualViewport events are all nice and shiny, but unfortunately not quite what is needed for the session store. Firstly, the spec wants the "scroll" event to be fired only when the *relative* offset between visual and layout viewport changes. The session store however records the absolute offset and as such is interested in when *that* changes. Secondly, again as per the spec the events don't bubble, and with the default DOMEventTargetHelper implementation they don't escape the VisualViewport during capturing, either. This means that any event listener must be added directly on the VisualViewport itself in order to capture any events. This might have been intended because the events use the same names as the normal "scroll"/"resize" events, and as such you cannot specify separate event listeners for VisualViewport and non-VisualViewport "scroll" events if both events end up being dispatched to the same element (you can only try to filter after the fact by looking at the originalTarget of the event). At the same time, the VisualViewport is attached to the inner Window, and so each time you navigate, you also get a different VisualViewport object. All of this might be totally fine from the perspective of a page script, because in that case you won't care anyway about what happens when the current page goes away. From the session store perspective on the other hand (especially Fennec's non- e10s session store design), this is rather unfortunate because we don't want to have to keep registering event listeners a) manually for each subframe b) each time the page navigates The event target chain problem could be solved by letting the scroll events escape the VisualViewport during the capturing phase (which the spec doesn't say anything about), but this would mean that any scroll listener attached to a window/browser/... that uses capturing will now catch both layout and visual viewport scroll events. In some cases this might even be beneficial, but in others (e.g. bug 1498812 comment 21) I'd like to specifically decide which kind of scroll event to capture. Having to look at event.originalTarget to distinguish the two kinds might be defensible in test code, but in case this distinction would be needed in production code as well, given the existence of a C++-based filtering helper in nsSessionStoreUtils for another use case where (scroll) events need to be filtered, JS-based scroll event filtering might be a bad idea. Additionally, in any case this wouldn't solve the fundamental conflict between the spec and the session store about *when* the "scroll" event should be fired in the first place. Hence I'd like to introduce a separate set of events with distinct event names, which will be dispatched according to the requirements of our internal users (i.e. currently the session store). To avoid potential web compatibility issues down the road, for now these events will be dispatched only to event listeners registered in the system group (allowing *all* Chrome event listeners cannot be done because checking the Chrome status of each event target might be too expensive for frequently dispatched events). Differential Revision: https://phabricator.services.mozilla.com/D14046 --HG-- extra : moz-landing-system : lando
101 lines
3.5 KiB
C++
101 lines
3.5 KiB
C++
/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
|
|
/* vim: set ts=8 sts=2 et sw=2 tw=80: */
|
|
/* This Source Code Form is subject to the terms of the Mozilla Public
|
|
* License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
|
|
|
|
#ifndef mozilla_dom_VisualViewport_h
|
|
#define mozilla_dom_VisualViewport_h
|
|
|
|
#include "mozilla/DOMEventTargetHelper.h"
|
|
#include "mozilla/dom/VisualViewportBinding.h"
|
|
#include "Units.h"
|
|
#include "nsIPresShell.h"
|
|
|
|
namespace mozilla {
|
|
namespace dom {
|
|
|
|
/* Visual Viewport API spec:
|
|
* https://wicg.github.io/visual-viewport/#the-visualviewport-interface */
|
|
class VisualViewport final : public mozilla::DOMEventTargetHelper {
|
|
public:
|
|
explicit VisualViewport(nsPIDOMWindowInner* aWindow);
|
|
|
|
double OffsetLeft() const;
|
|
double OffsetTop() const;
|
|
double PageLeft() const;
|
|
double PageTop() const;
|
|
double Width() const;
|
|
double Height() const;
|
|
double Scale() const;
|
|
IMPL_EVENT_HANDLER(resize)
|
|
IMPL_EVENT_HANDLER(scroll)
|
|
|
|
virtual JSObject* WrapObject(JSContext* aCx,
|
|
JS::Handle<JSObject*> aGivenProto) override;
|
|
void GetEventTargetParent(EventChainPreVisitor& aVisitor) override;
|
|
|
|
void PostResizeEvent();
|
|
void PostScrollEvent(const nsPoint& aPrevVisualOffset,
|
|
const nsPoint& aPrevLayoutOffset);
|
|
|
|
// These two events are modelled after the ScrollEvent class in
|
|
// nsGfxScrollFrame.h.
|
|
class VisualViewportResizeEvent : public Runnable {
|
|
public:
|
|
NS_DECL_NSIRUNNABLE
|
|
VisualViewportResizeEvent(VisualViewport* aViewport,
|
|
nsPresContext* aPresContext);
|
|
void Revoke() { mViewport = nullptr; }
|
|
|
|
private:
|
|
VisualViewport* mViewport;
|
|
};
|
|
|
|
class VisualViewportScrollEvent : public Runnable {
|
|
public:
|
|
NS_DECL_NSIRUNNABLE
|
|
VisualViewportScrollEvent(VisualViewport* aViewport,
|
|
nsPresContext* aPresContext,
|
|
const nsPoint& aPrevVisualOffset,
|
|
const nsPoint& aPrevLayoutOffset);
|
|
void Revoke() { mViewport = nullptr; }
|
|
nsPoint PrevVisualOffset() const { return mPrevVisualOffset; }
|
|
nsPoint PrevLayoutOffset() const { return mPrevLayoutOffset; }
|
|
|
|
private:
|
|
VisualViewport* mViewport;
|
|
// The VisualViewport "scroll" event is supposed to be fired only when the
|
|
// *relative* offset between visual and layout viewport changes. The two
|
|
// viewports are updated independently from each other, though, so the only
|
|
// thing we can do is note the fact that one of the inputs into the relative
|
|
// visual viewport offset changed and then check the offset again at the
|
|
// next refresh driver tick, just before the event is going to fire.
|
|
// Hopefully, at this point both visual and layout viewport positions have
|
|
// been updated, so that we're able to tell whether the relative offset did
|
|
// in fact change or not.
|
|
const nsPoint mPrevVisualOffset;
|
|
const nsPoint mPrevLayoutOffset;
|
|
};
|
|
|
|
private:
|
|
virtual ~VisualViewport();
|
|
|
|
CSSSize VisualViewportSize() const;
|
|
CSSPoint VisualViewportOffset() const;
|
|
CSSPoint LayoutViewportOffset() const;
|
|
nsIPresShell* GetPresShell() const;
|
|
nsPresContext* GetPresContext() const;
|
|
|
|
void FireResizeEvent();
|
|
void FireScrollEvent();
|
|
|
|
RefPtr<VisualViewportResizeEvent> mResizeEvent;
|
|
RefPtr<VisualViewportScrollEvent> mScrollEvent;
|
|
};
|
|
|
|
} // namespace dom
|
|
} // namespace mozilla
|
|
|
|
#endif // mozilla_dom_VisualViewport_h
|