This allows it to be forward-declared (while a nested class cannot be),
such that headers files that use RectCallback by pointer or reference
do not need to include nsLayoutUtils.h.
This avoids including nsLayoutUtils.h in nsRange.h.
Differential Revision: https://phabricator.services.mozilla.com/D91685
This effectively reverts Bug 1441279 Part 6.
https://hg.mozilla.org/mozilla-central/rev/eab2985673a5
The original patch's extend commit message describes that if a
AccessibleCaretEventHub registers scroll and reflow observers only on the leaf
docshell, it fails to update caret position when an ancestor iframe is
scrolled.
I think the above statement is incorrect. When scrolling an ancestor
iframe, the visible caret in an inner iframe should scroll with other
elements by virtue of APZ. Also, `AccessibleCaret::SetPosition()` itself
detects whether its position is changed relative to the top level
absolute position container (the moz-custom-content-container under
CanvasFrame). When scrolling an ancestor iframe, AccessibleCaret's
position in the inner iframe should remain static (relative to the inner
frame.)
Differential Revision: https://phabricator.services.mozilla.com/D84873
This "upgrades" various nsLayoutUtils functions which take as inputs
a set of coordinates and a frame that the coordinates are relative to,
to accept a RelativeTo object instead of a frame.
Most of the patch is just dumb propagation, but the few places where
we use an explicit ViewportType::Visual are important. There are
probably a few other places I've overlooked, but this seems to cover
the important ones that come up commonly.
There are undoubtedly other functions into which we can propagate
RelativeTo, in this patch I've propagated it as far as necessary
for my needs in this bug (mainly GetTransformToAncestor() and
GetEventCoordinatesRelativeTo()).
Differential Revision: https://phabricator.services.mozilla.com/D68919
This "upgrades" various nsLayoutUtils functions which take as inputs
a set of coordinates and a frame that the coordinates are relative to,
to accept a RelativeTo object instead of a frame.
Most of the patch is just dumb propagation, but the few places where
we use an explicit ViewportType::Visual are important. There are
probably a few other places I've overlooked, but this seems to cover
the important ones that come up commonly.
There are undoubtedly other functions into which we can propagate
RelativeTo, in this patch I've propagated it as far as necessary
for my needs in this bug (mainly GetTransformToAncestor() and
GetEventCoordinatesRelativeTo()).
Differential Revision: https://phabricator.services.mozilla.com/D68919
Long-pressing on a text in an unfocused iframe to select a word never
works. Currently, you need to single tap to focus the iframe first.
Each PresShell has an associated AccessibleCaretEventHub. This patch
fixes this bug by routing the event to the AccessibleCaretEventHub under
the event point, and handle it there. If the event is not handled, then
we handle it by the focused AccessibleCaretEventHub as before.
I've experimented with only routing the event to the
AccessibleCaretEventHub under the event point, without routing to the
fallback focused AccessibleCaretEventHub. However, caret dragging didn't
work in iframes. I didn't debug further.
Differential Revision: https://phabricator.services.mozilla.com/D52767
--HG--
extra : moz-landing-system : lando
That is, we consume the synthesized mouse move events without doing
anything in PressCaretState and DragCaretState.
Differential Revision: https://phabricator.services.mozilla.com/D52113
--HG--
extra : moz-landing-system : lando
In common cases where the caret is in a position:static frame subtree,
the caret's position (relative to canvas frame's custom content
container) should not be changed during scrolling.
However, when the caret is in a position:fixed or "stuck"
position:sticky frame subtree, the caret's position will change during
scrolling. We need to disable APZ to avoid jumpy carets.
Differential Revision: https://phabricator.services.mozilla.com/D51351
--HG--
extra : moz-landing-system : lando
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
That includes changing privacy.resistFingerprinting to a non-VarCache pref,
because it doesn't need to be a VarCache.
Differential Revision: https://phabricator.services.mozilla.com/D36162
--HG--
extra : rebase_source : 6d742e6ff2a4b786cb21f6e8874d1fd4bbde1857
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
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
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
This patch changes remaining things under `layout/`. However, there are some
places which still need to use `nsIPresShell`. That will be fixed in a
follow up bug.
Differential Revision: https://phabricator.services.mozilla.com/D27477
--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.
"layers.async-pan-zoom.enabled" has been enabled for all platforms for a
long time. I reword the comment to avoid confusion.
Differential Revision: https://phabricator.services.mozilla.com/D5471
--HG--
extra : moz-landing-system : lando
"layers.async-pan-zoom.enabled" has been enabled for all platforms for a
long time. I reword the comment to avoid confusion.
Differential Revision: https://phabricator.services.mozilla.com/D5471
AccessibleCaretEventHub is an nsISelectionListener of Selection whose type is
"normal". This is added only when nsFrameSelection::Init() is called and
accessible caret is enabled. Additionally, nsFrameSelection::Init() is
always called immediately after creating nsFrameSelection.
Therefore, when AccessibleCaretEventHub is installed to Selection, this is
always second selection listener and won't be installed multiple times. So,
Selection can store pointer of AccessibleCaretEventHub directly only when
it's enabled and the Selection needs to notify it of selection change.
This patch makes Selection stores AccessibleCaretEventHub with RefPtr, then,
makes Selection::NotifySelectionListeners() call its OnSelectionChange()
immediately after AutoCopyListener.
Unfortunately, this patch includes making of MOZ_CAN_RUN_SCRIPT_BOUNDARY and
MOZ_CAN_RUN_SCRIPT a lot since some methods of AccessibleCaretEventHub are
marked as MOZ_CAN_RUN_SCRIPT and including AccessibleCaretEventHub.h into
Selection.h causes compile the compile errors.
Differential Revision: https://phabricator.services.mozilla.com/D4733
--HG--
extra : moz-landing-system : lando
Avoid processing anon content in nsCanvasFrame, then getting more anon content
via AccessibleCaretEventHub::Init. Instead call Init before creating the custom
content container. We could also throw a script runner at it I guess, but this
prevents the reentrancy issue.
Avoid cloning nodes during layout, just use the same node (already cloned in
InsertAnonymousContent) instead.
The RemoveChild in GetAnonymousContent to handle the reframes instead of cloning
around is a bit hacky, but I don't think it's really worth extending
PostDestroyData for this special case.
Differential Revision: https://phabricator.services.mozilla.com/D1889
This commit just adds some #include directives and "using namespace" directives.
(The "using namespace mozilla::dom;" are the important namespace directives
here, though I've included "using namespace mozilla;" alongside it as well, for
completeness/consistency.)
Differential Revision: https://phabricator.services.mozilla.com/D1647
AccessibleCaretManager uses scroll and reflow observers to detect when
to update the position of carets. However, it currently only registers
the observers on the leaf docshell, so only changes in the innermost
iframe are detected; that is, it fails to update caret position when an
ancestor iframe is scrolled. This patch makes it register observers on
all ancestor docshells so that changes in ancestor iframes are detected
as well.
MozReview-Commit-ID: bwiSjj8936
--HG--
extra : rebase_source : d567f1d8df67f79769c6532b061e2df1e5ab878f
In the era of B2G, we wanted to hide the carets during scrolling, and
PostScrollState was designed to avoid carets flicking during momentum
scrolling.
These days, we no longer hide carets during scrolling, so PostScrollState
can be removed to make the code simpler and easier to maintain.
MozReview-Commit-ID: Bf6ZgYVlt1q
--HG--
extra : rebase_source : 272bf91b8acaae6d81a3291b6ad85703ff2696dc
The accessible caret manager is owned by the event hub, that is owned by the
shell.
All the callers of methods that call FlushLayout on the AccessibleCaretManager
should hold an external reference to the event hub.
Flushing pending notifications can run arbitrary script, that can call Destroy()
on the pres shell (and thus tear down the accessible caret event hub, and the
manager with him).
I don't know why before my change this wasn't crashing badly, but the code as it
was just doesn't look sound to me at all either (maybe I'm misunderstanding
something and I should just revert that patch and give up on having nice
invariants during our flushes..., but I don't think it's the case).
This also adds some sanity-checking that we don't die under our flush.
MozReview-Commit-ID: 4s0UT0fD3TI
Fix warning: 'virtual' is redundant since the function is already declared
'override'
MozReview-Commit-ID: Kps9ZZoFniI
--HG--
extra : rebase_source : aed811d199ed9d977648656ef9175ccac26206b8
Fix warning: use '= default' to define a trivial destructor
I added #include "nsDocShell.h" because I got an error "incomplete type
'nsDocShell' used in nested name specifier." After that, some files like
nsCanvasFrame.cpp fails to compile because they include
AccessibleCaretEventHub.h. Hence the moz.build changes.
MozReview-Commit-ID: BYZx7txvkSn
--HG--
extra : rebase_source : 2a4e8c25eb1c596486d540f2a5a34a00dc675881
Botond Ballo
Ting-Yu Lin
Kagami Sascha Rosylight
Csoregi Natalia
Kannan Vijayan
Nicholas Nethercote
Jean-Yves Avenard
Gurzau Raul
Srujana Peddinti
Masayuki Nakano
Ryan Hunt
Emilio Cobos Álvarez
Sylvestre Ledru
Ting-Yu Lin
Ryan VanderMeulen
Jeff Gilbert
Daniel Holbert
Boris Zbarsky
Jim Chen
Kris Maglione
Bill McCloskey
Carsten "Tomcat" Book