gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
This patch moves remaining public `enum` of `nsIPresShell` to `mozilla`
namespace in `mozilla/PresShellForwards.h` and make them `enum class`es.
Additionally, some methods which use the moving `enum`s from `nsIPresShell`
to `PresShell`.
Differential Revision: https://phabricator.services.mozilla.com/D28607
--HG--
extra : moz-landing-system : lando
Moved mozilla::WidgetMosueEventBase::buttonType in MouseEvents.h to mozilla::MouseButton in EventForwards.h, and mozilla::WidgetMouseEventBase::buttonsFlag to mozilla::MouseButtonsFlag so that any referer in header files do not need to include MouseEvents.h only for referring them. Instead, they just need to include EventForwards.h. Now when MouseEvents.h is changed, the rebuild speed becomes faster.
Differential Revision: https://phabricator.services.mozilla.com/D25325
--HG--
extra : moz-landing-system : lando
Renamed all class member instances from WidgetMouseEventBase::inputSource to WidgetMouseEventBase::mInputSource
Differential Revision: https://phabricator.services.mozilla.com/D25322
--HG--
extra : moz-landing-system : lando
Renamed all class member instances from WidgetMouseEventBase::button to WidgetMouseEventBase::mButton.
Differential Revision: https://phabricator.services.mozilla.com/D25309
--HG--
extra : moz-landing-system : lando
And this patch makes it return raw pointer. The safeness of the pointer
should be managed by `MOZ_CAN_RUN_SCRIPT` since incrementing refcount in
hot path is bad for performance. So, it should be followed by bug 1543315.
Differential Revision: https://phabricator.services.mozilla.com/D27471
--HG--
extra : moz-landing-system : lando
Some methods take `const nsCOMPtr<nsIPresShell>&` as their argument to make
their callers guarantee the lifetime. However, currently all of them are
marked as `MOZ_CAN_RUN_SCRIPT`. So, it's safe to change them to raw pointer.
Additionally, this patch makes them take `mozilla::PresShell*` directly
rather than via `nsIPresShell*`.
Differential Revision: https://phabricator.services.mozilla.com/D26456
--HG--
extra : moz-landing-system : lando
This patch makes `TabChild` use `mozilla::PresShell` directly.
Then, renames `TabChild::GetPresShell()` and `TabChild::GetDocument()` to
`TabChild::GetTopLevelPresShell()` and `TabChild::GetTopLevelDocument()` to
make what they do clearer (e.g., see the change in `PresShell.cpp`).
Differential Revision: https://phabricator.services.mozilla.com/D26455
--HG--
extra : moz-landing-system : lando
* Remove redundant virtual keywords
* Mark all destructors of inheriting classes as virtual for clarity
* Mark all classes without virtual destructor as final (exposed errors)
* Make destructor virtual where it needed to be (some were missing)
* Replace empty ({}) code declaration in header with = default
* Remove virtual unused methods
I probably missed some, it quickly became a rabbit hole.
Differential Revision: https://phabricator.services.mozilla.com/D26060
--HG--
extra : moz-landing-system : lando
This makes `Document::GetShell()` return `PresShell*` instead of `nsIPresShell`.
Additonally, "shell" is unclear ("docshell" vs. "presshell"). Therefore, this
also renames `Document::GetShell()` to `Document::GetPresShell()`.
Similarly, some other method names of `Document` are also renamed from
`*Shell*` to `*PresShell*`.
Differential Revision: https://phabricator.services.mozilla.com/D25338
--HG--
extra : moz-landing-system : lando
This makes `Document::GetShell()` return `PresShell*` instead of `nsIPresShell`.
Additonally, "shell" is unclear ("docshell" vs. "presshell"). Therefore, this
also renames `Document::GetShell()` to `Document::GetPresShell()`.
Similarly, some other method names of `Document` are also renamed from
`*Shell*` to `*PresShell*`.
Differential Revision: https://phabricator.services.mozilla.com/D25338
--HG--
extra : moz-landing-system : lando
This is a large patch that contains all of the core changes for
renderroot splitting.
Differential Revision: https://phabricator.services.mozilla.com/D20701
--HG--
extra : moz-landing-system : lando
This is a large patch that contains all of the core changes for
renderroot splitting.
Differential Revision: https://phabricator.services.mozilla.com/D20701
--HG--
extra : moz-landing-system : lando
And rename the constants to not be prefixed by TOUCH_ACTION_, since that's part
of the type name anyway.
Differential Revision: https://phabricator.services.mozilla.com/D23413
--HG--
extra : moz-landing-system : lando
When walking up the frame parent chain to compute the touch-action on an
element, we should use the in-flow parent. This produces different
values for out-of-flow frames (e.g. fixed-position frames). This is more
in line with the actual spec for touch-action, which propagates down the
DOM.
Differential Revision: https://phabricator.services.mozilla.com/D23570
--HG--
extra : moz-landing-system : lando
Other mobile browsers disallow browser-based pinch zooming when the
first touchstart is preventDefaulted, even if the second one is not. We
allowed pinch zooming in that scenario. This patch makes it so that if
the first touchstart is preventDefaulted, then subsequent touchstart
events are also preventDefaulted, which brings our behaviour in line
with that of other browsers.
Differential Revision: https://phabricator.services.mozilla.com/D21420
--HG--
extra : moz-landing-system : lando
Other mobile browsers disallow browser-based pinch zooming when the
first touchstart is preventDefaulted, even if the second one is not. We
allowed pinch zooming in that scenario. This patch makes it so that if
the first touchstart is preventDefaulted, then subsequent touchstart
events are also preventDefaulted, which brings our behaviour in line
with that of other browsers.
Differential Revision: https://phabricator.services.mozilla.com/D21420
--HG--
extra : moz-landing-system : lando
Chrome synthesizes mousemove event and related events (mouseover, mouseenter,
etc) when context menu event is fired by long tap. This allows users to open
submenu which is opened by moving mouse cursor over a link.
So, this fix improves accessibility of our users on some websites which are
designed for desktop.
Differential Revision: https://phabricator.services.mozilla.com/D14857
--HG--
extra : moz-landing-system : lando
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
There is no reason to use nsAtoms*, it's error prone, i.e. the function
can take arbitrary nsAtoms*.
Depends on D15339
Differential Revision: https://phabricator.services.mozilla.com/D15340
--HG--
extra : moz-landing-system : lando
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
Internally, Gecko stores and updates the *absolute* offset between the visual
viewport and the page, however the spec demands that the scroll event be fired
whenever the *relative* offset between visual and layout viewport changes.
Differential Revision: https://phabricator.services.mozilla.com/D14044
--HG--
extra : moz-landing-system : lando
Also add an IsElement check in GetElementFromPoint in the APZ code since I think
the element cast is unsound in presence of Shadow DOM.
Differential Revision: https://phabricator.services.mozilla.com/D14355
--HG--
extra : moz-landing-system : lando
The tracking is done using nsAtom origins, similarly to how updates to the
scroll offset are tracked.
Currently, APZ still uses some heuristics to deduce that the main thread
originated a resolution change in some cases, but the intention is to try
to remove those and rely only on this mechanism in the future.
Differential Revision: https://phabricator.services.mozilla.com/D13741
--HG--
extra : moz-landing-system : lando
This adds a notification from APZ to the scrollbar's slider frame to
inform it of APZ starting an async scrollbar drag. This is useful
because APZ can start a scrollbar drag and even change the scroll
position before the scrollbar frame even handles the mousedown event. In
such a case, the mousedown can land on where the scrollthumb *used to
be* before it was dragged away. This can result in scroll-to-click
behavior getting triggered and the scrollthumb glitching.
With this patch, the new notification follows the same path as the
request-repaint message, and so is guaranteed to arrive at the scrollbar
before any request-repaint messages. It sets some state that can be used
to correct the behaviour described above.
Differential Revision: https://phabricator.services.mozilla.com/D12364
--HG--
extra : moz-landing-system : lando
This commit attempts to lower the pain of modifying FrameMetrics.h.
It looks like most includes really only want ViewID or
ScrollableLayerGuid, so this commit factors them out into a separate
header. In the process FrameMetrics::ViewID is changed to
ScrollableLayerGuid::ViewID, which personally seems like a better
place for it now that we have RepaintRequest. Unfortunately that
requires a lot of places to be updated.
After this commit there are still a couple of major places that
FrameMetrics is included.
* nsDisplayList.h
* nsIScrollableFrame.h
* Layers.h
Those are going to be more tricky or impossible to fix so they're
not in this commit.
Differential Revision: https://phabricator.services.mozilla.com/D10722
--HG--
rename : gfx/layers/FrameMetrics.h => gfx/layers/ScrollableLayerGuid.h
rename : gfx/layers/FrameMetrics.h => gfx/layers/ZoomConstraints.h
extra : rebase_source : 29ac79f91460a181bf7437af5c371207e22858e2
extra : source : c2e70e531075493fc6e374dcec862827f0bc6e77
When APZUpdater::mUpdaterQueue still contains entries, and it is
destroyed, we may trip an assert due to destroying an already_AddRefed
object without taking its contents into a RefPtr. This is because
APZUpdater::RunOnControllerThread would pass an already_AddRefed object
directly into NewRunnableFunction as the object, instead of a RefPtr
object. This caused templated object to store an already_AddRefed object
as a result, and when we wanted to drop the object, it complained.
Storing it as a RefPtr should cause everything to be freed normally.
Differential Revision: https://phabricator.services.mozilla.com/D9702
FrameMetrics is currently used in about three ways.
1. Main thread to APZ transactions
2. Storing information in AsyncPanZoomController
3. APZ to main thread repaint requests
There's overlap in the use of fields in all these use cases, but it's not perfect. In a
following commit, I'd like to change the information used for (1) to support relative
scroll offset updates. This information isn't needed for (2) or (3), so it would be
good to refactor FrameMetrics out into these use cases.
This commit refactors out (3) as it is fairly easy to do. I'd like to refactor (2) out
as well, but that is trickier. I'd like to leave that for a future followup.
Differential Revision: https://phabricator.services.mozilla.com/D7127
--HG--
extra : rebase_source : f0be2be24fce7d0f0ed25f6f3bfab5f7f2864f23
extra : source : fc9898a9ab28cee292e201ddaf757ee267179433
extra : histedit_source : 35415d3dc2c0ae0f269994c385cceff75f150020
This change also renames several related functions, as well as fields,
and the header is moved into EXPORTS.mozilla given it is defined under
mozilla namespace.
MozReview-Commit-ID: LqCdcW8fmUN
--HG--
rename : layout/base/ScrollbarStyles.cpp => layout/base/ScrollStyles.cpp
rename : layout/base/ScrollbarStyles.h => layout/base/ScrollStyles.h
extra : rebase_source : 8933f3bca88d5db4b9508e3947f695ecf7511b3e
There is a race between when APZ is made aware of a main thread change to a
frame's overflow property and when it decides whether to allow scrolling in
response to an input event. If the processing of the input event wins the race,
APZ can allow scrolling an element that has recently been made overflow:hidden.
The main thread previously asserted about the attempt to scroll an
overflow:hidden element, but since this can occur in practice, is relatively
benign, and is hard to avoid, we will now allow it.
MozReview-Commit-ID: IkH7xWyMOEl
--HG--
extra : rebase_source : 9d5ca0986979ba570f8cab481ac9da5eed43f35a
Added a data member to nsIPresShell to store the visual viewport offset. APZ
will update the visual viewport offset in the presShell for root scroll frames
on every repaint request.
MozReview-Commit-ID: Ksou43hrE6H
--HG--
extra : rebase_source : 812c88efc7556c4bff2a62834cfaaec6e6945093
There are 3 main components to this change:
a) Store the origin of the layout viewport in APZ (until now we only stored
it's size). This required updating the offset stored in mViewport, which
was previously (0, 0).
b) Adjust the layout viewport in APZ each time the visual viewport exceeds
the bounds of the layout viewport.
c) Update the main thread to store the layout viewport offset for the
RCD-RSF (currently it uses the layout viewport offset for overflow:hidden
pages, and the visual viewport offset otherwise).
MozReview-Commit-ID: 7AD8wvthh2m
--HG--
extra : rebase_source : df8704146740f4b2522c80b20b603617993b6c83
Originally, DisplayPort suppression was a process-global static. This change makes it possible
to control DisplayPort suppression on a per-PresShell basis.
Differential Revision: https://phabricator.services.mozilla.com/D1759
This comment is wrong because the scrollbar might have scheduled a
post-refresh confirmation, which would not have been sent yet. So if we
sent the preventDefault flag as true, APZ would drop the block improperly,
because the drag block might later (as part of the post-refresh) get
confirmed.
MozReview-Commit-ID: HKzMatUOeiG
--HG--
extra : rebase_source : 03c4289e028799228c23d600c09592febd3824e7
In the case where an inactive scrollframe's scrollbar gets dragged, the
main thread layerizes the scrollframe and dispatches both a
SetTargetAPZC message and a AsyncDragMetrics message using post-refresh
observers. However, the post-refresh observers are registered such that
the SetTargetAPZC message gets sent first, and APZ will start
processing the drag block immediately upon receipt of that event. This
means that the APZC might not have the correct drag metrics when it
processes those input events. For correct behaviour, we want the
AsyncDragMetrics message to reach APZ first in this scenario, and this
patch accomplishes this by allowing the post-refresh observers to be
registered in the opposite order.
MozReview-Commit-ID: 6LzyYYG1t6F
--HG--
extra : rebase_source : 2e3ebaa4fd776c8ad17e8225d70ec4a18eee67e0
No functional changes here, but this updates the documentation in
InputAPZContext and separates the fields into two categories for easier
understanding. This is what I had in mind when I introduced this class
but never documented it anywhere, and so the "pending layerization" flag
didn't follow the convention that I had in mind. This cleans that up.
MozReview-Commit-ID: I26Ocu5Uco2
--HG--
extra : rebase_source : 8e0e096f6a98626624e3d62f89d0ffea2049cd8c
- Fix the implementation to return a numerically correct result
- Change call sites that should have instead been using
CalculateCompositedSizeInCssPixels(), to do so
- Rename and document to emphasize that the returned rect is in the
CSS pixels of the content surrounding the scroll frame
MozReview-Commit-ID: GCPbA1k88rz
--HG--
extra : rebase_source : f5b937936fb84b3ae414d6cf0250add4078a9d53
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
This patch basically does:
* remove StyleSetHandle and its corresponding files
* revisit #includes of related header files and change correspondingly
* change nsIPresShell::mStyleSet to be UniquePtr<ServoStyleSet>
* change the creating path of ServoStyleSet to pass UniquePtr
* change other mentions of StyleSetHandle to ServoStyleSet*
* remove AsServo() calls on ServoStyleSet
Some unfortunate bits:
* some methods of (Servo)StyleSet only accepts ServoStyleSheet while
many places call into the methods with StyleSheet, so there are many
->AsServo() added to sheets
MozReview-Commit-ID: K4zYnuhOurA
--HG--
extra : rebase_source : 459e8efeb171adad089d94272e143e8c244bd279
extra : source : 65ba2f174fcf7dba4e59c00ee8908b1bd0820a48
Note that this also makes the utility functions instance methods,
because each APZSampler might have a different sampler thread instance.
MozReview-Commit-ID: 9dY8ZzVX6lR
--HG--
extra : rebase_source : 4dd58400aee5d9f2063abe0a912488b28ff74f9f
Currently the ZoomToRect function is only ever called on Android, on the
UI process main thread, which is neither the controller nor the sampler
thread. Instead of allowing "random" threads to run inside APZ, we
ensure that callers run it on the controller thread.
Without this patch, UpdateZoomConstraints can get called on:
a) the compositor/sampler thread (over PAPZCTreeManager)
b) the controller thread which is also the UI process main thread (on
desktop platforms without a GPU process)
c) the UI process main thread when it's *not* the controller thread (on
Android).
Instead of having to reason about all these scenarios separately, we can
try to unify them a little bit by ensuring the function contents always
run on the sampler thread, which is the thread that seems to make the
most sense for it.
The sampler thread is similar to the controller thread in that it doesn't
correspond to a particular actual thread, but instead introduces an
abstraction that allows us to reason about code flow and data ownership
that is logically grouped on a single thread. For now the sampler thread
remains mapped to the compositor thread, but eventually we will allow
it to be render backend thread when webrender is enabled.
MozReview-Commit-ID: D6i2t5lDvkv
--HG--
extra : rebase_source : 06211ad878973c76ca3fd618386bbbd0cfdd4821
Jean-Yves Avenard
Sylvestre Ledru
Gurzau Raul
arthur.iakab
Kartikaya Gupta
Dorel Luca
Matt Woodrow
Masayuki Nakano
Ryan Hunt
Srujana Peddinti
Doug Thayer
Ciure Andrei
Emilio Cobos Álvarez
Brad Werth
shindli
Botond Ballo
Boris Zbarsky
Henri Sivonen
Ehsan Akhgari
Jan Henning
Hiroyuki Ikezoe
Andrew Osmond
sotaro
Arika Arnzen
Ting-Yu Lin
Xidorn Quan
Kashav Madan
Tanushree Podder
Jeff Gilbert
Mike Conley
Peter Bacalso
Cameron McCormack
Stone Shih