2018-08-20 23:28:42 +03:00
|
|
|
/* -*- 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"
|
2019-04-10 21:36:42 +03:00
|
|
|
#include "mozilla/WeakPtr.h"
|
2018-08-20 23:28:42 +03:00
|
|
|
#include "mozilla/dom/VisualViewportBinding.h"
|
|
|
|
#include "Units.h"
|
|
|
|
|
|
|
|
namespace mozilla {
|
2019-04-13 04:03:13 +03:00
|
|
|
|
|
|
|
class PresShell;
|
|
|
|
|
2018-08-20 23:28:42 +03:00
|
|
|
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;
|
2019-05-09 06:56:41 +03:00
|
|
|
MOZ_CAN_RUN_SCRIPT double Width() const;
|
|
|
|
MOZ_CAN_RUN_SCRIPT double Height() const;
|
2018-08-20 23:28:42 +03:00
|
|
|
double Scale() const;
|
2018-12-21 20:08:47 +03:00
|
|
|
IMPL_EVENT_HANDLER(resize)
|
|
|
|
IMPL_EVENT_HANDLER(scroll)
|
2018-08-20 23:28:42 +03:00
|
|
|
|
|
|
|
virtual JSObject* WrapObject(JSContext* aCx,
|
|
|
|
JS::Handle<JSObject*> aGivenProto) override;
|
Bug 1478776 - Part 10: Add internal VisualViewport resize/scroll events. r=botond,nika
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
2018-12-21 01:14:42 +03:00
|
|
|
void GetEventTargetParent(EventChainPreVisitor& aVisitor) override;
|
2018-08-20 23:28:42 +03:00
|
|
|
|
2018-12-21 00:35:26 +03:00
|
|
|
void PostResizeEvent();
|
Bug 1478776 - Part 10: Add internal VisualViewport resize/scroll events. r=botond,nika
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
2018-12-21 01:14:42 +03:00
|
|
|
void PostScrollEvent(const nsPoint& aPrevVisualOffset,
|
|
|
|
const nsPoint& aPrevLayoutOffset);
|
2018-12-21 00:35:26 +03:00
|
|
|
|
|
|
|
// 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);
|
2019-04-10 21:36:42 +03:00
|
|
|
bool HasPresContext(nsPresContext* aContext) const;
|
|
|
|
void Revoke();
|
2018-12-21 00:35:26 +03:00
|
|
|
|
|
|
|
private:
|
|
|
|
VisualViewport* mViewport;
|
2019-04-10 21:36:42 +03:00
|
|
|
WeakPtr<nsPresContext> mPresContext;
|
2018-12-21 00:35:26 +03:00
|
|
|
};
|
|
|
|
|
|
|
|
class VisualViewportScrollEvent : public Runnable {
|
|
|
|
public:
|
|
|
|
NS_DECL_NSIRUNNABLE
|
|
|
|
VisualViewportScrollEvent(VisualViewport* aViewport,
|
2018-12-21 00:35:38 +03:00
|
|
|
nsPresContext* aPresContext,
|
Bug 1478776 - Part 10: Add internal VisualViewport resize/scroll events. r=botond,nika
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
2018-12-21 01:14:42 +03:00
|
|
|
const nsPoint& aPrevVisualOffset,
|
|
|
|
const nsPoint& aPrevLayoutOffset);
|
2019-04-10 21:36:42 +03:00
|
|
|
bool HasPresContext(nsPresContext* aContext) const;
|
|
|
|
void Revoke();
|
Bug 1478776 - Part 10: Add internal VisualViewport resize/scroll events. r=botond,nika
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
2018-12-21 01:14:42 +03:00
|
|
|
nsPoint PrevVisualOffset() const { return mPrevVisualOffset; }
|
|
|
|
nsPoint PrevLayoutOffset() const { return mPrevLayoutOffset; }
|
2018-12-21 00:35:26 +03:00
|
|
|
|
|
|
|
private:
|
|
|
|
VisualViewport* mViewport;
|
2019-04-10 21:36:42 +03:00
|
|
|
WeakPtr<nsPresContext> mPresContext;
|
2018-12-21 00:35:38 +03:00
|
|
|
// 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.
|
Bug 1478776 - Part 10: Add internal VisualViewport resize/scroll events. r=botond,nika
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
2018-12-21 01:14:42 +03:00
|
|
|
const nsPoint mPrevVisualOffset;
|
|
|
|
const nsPoint mPrevLayoutOffset;
|
2018-12-21 00:35:26 +03:00
|
|
|
};
|
|
|
|
|
2018-08-20 23:28:42 +03:00
|
|
|
private:
|
|
|
|
virtual ~VisualViewport();
|
|
|
|
|
2019-05-09 06:56:41 +03:00
|
|
|
MOZ_CAN_RUN_SCRIPT CSSSize VisualViewportSize() const;
|
2018-08-20 23:28:42 +03:00
|
|
|
CSSPoint VisualViewportOffset() const;
|
|
|
|
CSSPoint LayoutViewportOffset() const;
|
2019-05-09 06:56:41 +03:00
|
|
|
Document* GetDocument() const;
|
2019-04-13 04:03:13 +03:00
|
|
|
PresShell* GetPresShell() const;
|
2018-12-21 00:35:26 +03:00
|
|
|
nsPresContext* GetPresContext() const;
|
|
|
|
|
|
|
|
void FireResizeEvent();
|
|
|
|
void FireScrollEvent();
|
|
|
|
|
|
|
|
RefPtr<VisualViewportResizeEvent> mResizeEvent;
|
|
|
|
RefPtr<VisualViewportScrollEvent> mScrollEvent;
|
2018-08-20 23:28:42 +03:00
|
|
|
};
|
|
|
|
|
|
|
|
} // namespace dom
|
|
|
|
} // namespace mozilla
|
|
|
|
|
|
|
|
#endif // mozilla_dom_VisualViewport_h
|