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/. */
|
|
|
|
|
|
|
|
#include "VisualViewport.h"
|
2018-12-21 00:35:26 +03:00
|
|
|
|
|
|
|
#include "mozilla/EventDispatcher.h"
|
2018-12-21 00:35:38 +03:00
|
|
|
#include "mozilla/ToString.h"
|
2018-08-20 23:28:42 +03:00
|
|
|
#include "nsIScrollableFrame.h"
|
|
|
|
#include "nsIDocShell.h"
|
2018-12-21 00:35:26 +03:00
|
|
|
#include "nsPresContext.h"
|
|
|
|
#include "nsRefreshDriver.h"
|
|
|
|
|
|
|
|
#define VVP_LOG(...)
|
|
|
|
// #define VVP_LOG(...) printf_stderr("VVP: " __VA_ARGS__)
|
2018-08-20 23:28:42 +03:00
|
|
|
|
|
|
|
using namespace mozilla;
|
|
|
|
using namespace mozilla::dom;
|
|
|
|
|
|
|
|
VisualViewport::VisualViewport(nsPIDOMWindowInner* aWindow)
|
|
|
|
: DOMEventTargetHelper(aWindow) {}
|
|
|
|
|
2018-12-21 00:35:26 +03:00
|
|
|
VisualViewport::~VisualViewport() {
|
|
|
|
if (mResizeEvent) {
|
|
|
|
mResizeEvent->Revoke();
|
|
|
|
}
|
|
|
|
|
|
|
|
if (mScrollEvent) {
|
|
|
|
mScrollEvent->Revoke();
|
|
|
|
}
|
|
|
|
}
|
2018-08-20 23:28:42 +03:00
|
|
|
|
|
|
|
/* virtual */
|
|
|
|
JSObject* VisualViewport::WrapObject(JSContext* aCx,
|
|
|
|
JS::Handle<JSObject*> aGivenProto) {
|
|
|
|
return VisualViewport_Binding::Wrap(aCx, this, aGivenProto);
|
|
|
|
}
|
|
|
|
|
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
|
|
|
/* virtual */
|
|
|
|
void VisualViewport::GetEventTargetParent(EventChainPreVisitor& aVisitor) {
|
|
|
|
EventMessage msg = aVisitor.mEvent->mMessage;
|
|
|
|
|
|
|
|
aVisitor.mCanHandle = true;
|
|
|
|
EventTarget* parentTarget = nullptr;
|
|
|
|
// Only our special internal events are allowed to escape the
|
|
|
|
// Visual Viewport and be dispatched further up the DOM tree.
|
|
|
|
if (msg == eMozVisualScroll || msg == eMozVisualResize) {
|
|
|
|
if (nsPIDOMWindowInner* win = GetOwner()) {
|
|
|
|
if (nsIDocument* doc = win->GetExtantDoc()) {
|
|
|
|
parentTarget = doc;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
aVisitor.SetParentTarget(parentTarget, false);
|
|
|
|
}
|
|
|
|
|
2018-08-20 23:28:42 +03:00
|
|
|
CSSSize VisualViewport::VisualViewportSize() const {
|
|
|
|
CSSSize size = CSSSize(0, 0);
|
|
|
|
|
|
|
|
nsIPresShell* presShell = GetPresShell();
|
|
|
|
if (presShell) {
|
|
|
|
if (presShell->IsVisualViewportSizeSet()) {
|
|
|
|
size = CSSRect::FromAppUnits(presShell->GetVisualViewportSize());
|
|
|
|
} else {
|
|
|
|
nsIScrollableFrame* sf = presShell->GetRootScrollFrameAsScrollable();
|
|
|
|
if (sf) {
|
|
|
|
size = CSSRect::FromAppUnits(sf->GetScrollPortRect().Size());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return size;
|
|
|
|
}
|
|
|
|
|
|
|
|
double VisualViewport::Width() const {
|
|
|
|
CSSSize size = VisualViewportSize();
|
|
|
|
return size.width;
|
|
|
|
}
|
|
|
|
|
|
|
|
double VisualViewport::Height() const {
|
|
|
|
CSSSize size = VisualViewportSize();
|
|
|
|
return size.height;
|
|
|
|
}
|
|
|
|
|
|
|
|
double VisualViewport::Scale() const {
|
|
|
|
double scale = 1;
|
|
|
|
nsIPresShell* presShell = GetPresShell();
|
|
|
|
if (presShell) {
|
|
|
|
scale = presShell->GetResolution();
|
|
|
|
}
|
|
|
|
return scale;
|
|
|
|
}
|
|
|
|
|
|
|
|
CSSPoint VisualViewport::VisualViewportOffset() const {
|
|
|
|
CSSPoint offset = CSSPoint(0, 0);
|
|
|
|
|
|
|
|
nsIPresShell* presShell = GetPresShell();
|
|
|
|
if (presShell) {
|
|
|
|
offset = CSSPoint::FromAppUnits(presShell->GetVisualViewportOffset());
|
|
|
|
}
|
|
|
|
return offset;
|
|
|
|
}
|
|
|
|
|
|
|
|
CSSPoint VisualViewport::LayoutViewportOffset() const {
|
|
|
|
CSSPoint offset = CSSPoint(0, 0);
|
|
|
|
|
2018-12-21 00:35:55 +03:00
|
|
|
if (nsIPresShell* presShell = GetPresShell()) {
|
|
|
|
offset = CSSPoint::FromAppUnits(presShell->GetLayoutViewportOffset());
|
2018-08-20 23:28:42 +03:00
|
|
|
}
|
|
|
|
return offset;
|
|
|
|
}
|
|
|
|
|
|
|
|
double VisualViewport::PageLeft() const { return VisualViewportOffset().X(); }
|
|
|
|
|
|
|
|
double VisualViewport::PageTop() const { return VisualViewportOffset().Y(); }
|
|
|
|
|
|
|
|
double VisualViewport::OffsetLeft() const {
|
|
|
|
return PageLeft() - LayoutViewportOffset().X();
|
|
|
|
}
|
|
|
|
|
|
|
|
double VisualViewport::OffsetTop() const {
|
|
|
|
return PageTop() - LayoutViewportOffset().Y();
|
|
|
|
}
|
|
|
|
|
|
|
|
nsIPresShell* VisualViewport::GetPresShell() const {
|
|
|
|
nsCOMPtr<nsPIDOMWindowInner> window = GetOwner();
|
|
|
|
if (!window) {
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
|
|
|
|
nsIDocShell* docShell = window->GetDocShell();
|
|
|
|
if (!docShell) {
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
|
|
|
|
return docShell->GetPresShell();
|
|
|
|
}
|
2018-12-21 00:35:26 +03:00
|
|
|
|
|
|
|
nsPresContext* VisualViewport::GetPresContext() const {
|
|
|
|
nsIPresShell* presShell = GetPresShell();
|
|
|
|
if (!presShell) {
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
|
|
|
|
return presShell->GetPresContext();
|
|
|
|
}
|
|
|
|
|
|
|
|
/* ================= Resize event handling ================= */
|
|
|
|
|
|
|
|
void VisualViewport::PostResizeEvent() {
|
|
|
|
VVP_LOG("%p: PostResizeEvent\n", this);
|
|
|
|
if (mResizeEvent) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// The event constructor will register itself with the refresh driver.
|
|
|
|
if (nsPresContext* presContext = GetPresContext()) {
|
|
|
|
mResizeEvent = new VisualViewportResizeEvent(this, presContext);
|
|
|
|
VVP_LOG("%p: PostResizeEvent, created new event\n", this);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
VisualViewport::VisualViewportResizeEvent::VisualViewportResizeEvent(
|
|
|
|
VisualViewport* aViewport, nsPresContext* aPresContext)
|
|
|
|
: Runnable("VisualViewport::VisualViewportResizeEvent"),
|
|
|
|
mViewport(aViewport) {
|
|
|
|
aPresContext->RefreshDriver()->PostVisualViewportResizeEvent(this);
|
|
|
|
}
|
|
|
|
|
|
|
|
NS_IMETHODIMP
|
|
|
|
VisualViewport::VisualViewportResizeEvent::Run() {
|
|
|
|
if (mViewport) {
|
|
|
|
mViewport->FireResizeEvent();
|
|
|
|
}
|
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
void VisualViewport::FireResizeEvent() {
|
|
|
|
MOZ_ASSERT(mResizeEvent);
|
|
|
|
mResizeEvent->Revoke();
|
|
|
|
mResizeEvent = nullptr;
|
|
|
|
|
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
|
|
|
VVP_LOG("%p, FireResizeEvent, fire mozvisualresize\n", this);
|
|
|
|
WidgetEvent mozEvent(true, eMozVisualResize);
|
|
|
|
mozEvent.mFlags.mOnlySystemGroupDispatch = true;
|
|
|
|
EventDispatcher::Dispatch(this, GetPresContext(), &mozEvent);
|
|
|
|
|
2018-12-21 00:35:26 +03:00
|
|
|
VVP_LOG("%p, FireResizeEvent, fire VisualViewport resize\n", this);
|
|
|
|
WidgetEvent event(true, eResize);
|
|
|
|
event.mFlags.mBubbles = false;
|
|
|
|
event.mFlags.mCancelable = false;
|
|
|
|
EventDispatcher::Dispatch(this, GetPresContext(), &event);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* ================= Scroll event handling ================= */
|
|
|
|
|
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 VisualViewport::PostScrollEvent(const nsPoint& aPrevVisualOffset,
|
|
|
|
const nsPoint& aPrevLayoutOffset) {
|
|
|
|
VVP_LOG("%p: PostScrollEvent, prevRelativeOffset=%s\n", this,
|
|
|
|
ToString(aPrevVisualOffset - aPrevLayoutOffset).c_str());
|
2018-12-21 00:35:26 +03:00
|
|
|
if (mScrollEvent) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// The event constructor will register itself with the refresh driver.
|
|
|
|
if (nsPresContext* presContext = GetPresContext()) {
|
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
|
|
|
mScrollEvent = new VisualViewportScrollEvent(
|
|
|
|
this, presContext, aPrevVisualOffset, aPrevLayoutOffset);
|
2018-12-21 00:35:26 +03:00
|
|
|
VVP_LOG("%p: PostScrollEvent, created new event\n", this);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
VisualViewport::VisualViewportScrollEvent::VisualViewportScrollEvent(
|
2018-12-21 00:35:38 +03:00
|
|
|
VisualViewport* aViewport, 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)
|
2018-12-21 00:35:26 +03:00
|
|
|
: Runnable("VisualViewport::VisualViewportScrollEvent"),
|
2018-12-21 00:35:38 +03:00
|
|
|
mViewport(aViewport),
|
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
|
|
|
mPrevVisualOffset(aPrevVisualOffset),
|
|
|
|
mPrevLayoutOffset(aPrevLayoutOffset) {
|
2018-12-21 00:35:26 +03:00
|
|
|
aPresContext->RefreshDriver()->PostVisualViewportScrollEvent(this);
|
|
|
|
}
|
|
|
|
|
|
|
|
NS_IMETHODIMP
|
|
|
|
VisualViewport::VisualViewportScrollEvent::Run() {
|
|
|
|
if (mViewport) {
|
|
|
|
mViewport->FireScrollEvent();
|
|
|
|
}
|
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
void VisualViewport::FireScrollEvent() {
|
|
|
|
MOZ_ASSERT(mScrollEvent);
|
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 = mScrollEvent->PrevVisualOffset();
|
|
|
|
nsPoint prevLayoutOffset = mScrollEvent->PrevLayoutOffset();
|
2018-12-21 00:35:26 +03:00
|
|
|
mScrollEvent->Revoke();
|
|
|
|
mScrollEvent = nullptr;
|
|
|
|
|
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
|
|
|
if (nsIPresShell* presShell = GetPresShell()) {
|
|
|
|
if (presShell->GetVisualViewportOffset() != prevVisualOffset) {
|
|
|
|
// The internal event will be fired whenever the visual viewport's
|
|
|
|
// *absolute* offset changed, i.e. relative to the page.
|
|
|
|
VVP_LOG("%p: FireScrollEvent, fire mozvisualscroll\n", this);
|
|
|
|
WidgetEvent mozEvent(true, eMozVisualScroll);
|
|
|
|
mozEvent.mFlags.mOnlySystemGroupDispatch = true;
|
|
|
|
EventDispatcher::Dispatch(this, GetPresContext(), &mozEvent);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Check whether the relative visual viewport offset actually changed -
|
|
|
|
// maybe both visual and layout viewport scrolled together and there was no
|
|
|
|
// change after all.
|
2018-12-21 00:35:38 +03:00
|
|
|
nsPoint curRelativeOffset =
|
|
|
|
presShell->GetVisualViewportOffsetRelativeToLayoutViewport();
|
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 prevRelativeOffset = prevVisualOffset - prevLayoutOffset;
|
2018-12-21 00:35:38 +03:00
|
|
|
VVP_LOG(
|
|
|
|
"%p: FireScrollEvent, curRelativeOffset %s, "
|
|
|
|
"prevRelativeOffset %s\n",
|
|
|
|
this, ToString(curRelativeOffset).c_str(),
|
|
|
|
ToString(prevRelativeOffset).c_str());
|
|
|
|
if (curRelativeOffset != prevRelativeOffset) {
|
|
|
|
VVP_LOG("%p, FireScrollEvent, fire VisualViewport scroll\n", this);
|
|
|
|
WidgetGUIEvent event(true, eScroll, nullptr);
|
|
|
|
event.mFlags.mBubbles = false;
|
|
|
|
event.mFlags.mCancelable = false;
|
|
|
|
EventDispatcher::Dispatch(this, GetPresContext(), &event);
|
|
|
|
}
|
|
|
|
}
|
2018-12-21 00:35:26 +03:00
|
|
|
}
|