Converted the following to StaticPrefs so that we can easily test variations:
NS_GC_DELAY
NS_SHRINK_GC_BUFFERS_DELAY
NS_FIRST_GC_DELAY
NS_FULL_GC_DELAY
NS_INTERSLICE_GC_DELAY
NS_USER_INTERACTION_INTERVAL
Differential Revision: https://phabricator.services.mozilla.com/D43112
--HG--
extra : moz-landing-system : lando
PresShell::EventHandler::HandleEventWithCurrentEventInfo is the only possible
place will do such handling; other places pass either a nullptr or a
non-MouseDown/Up event.
Differential Revision: https://phabricator.services.mozilla.com/D32431
--HG--
extra : moz-landing-system : lando
Additionally, this patch makes `nsContentUtils::DispatchXULCommand()` because
it guarantees the lifetime of **only** `PresShell` in it. So, we need to check
the lifetime of each argument at each caller here.
Differential Revision: https://phabricator.services.mozilla.com/D29199
--HG--
extra : moz-landing-system : lando
So, this patch makes all caller of it safe including its arguments unless
they come from other methods.
Differential Revision: https://phabricator.services.mozilla.com/D27225
--HG--
extra : moz-landing-system : lando
And for now, start blocking custom cursors that are larger than 64 pixels.
I wish I knew how to add a test for this, but I tested manually using the
test-case from bug 1518189 with and without hidpi.
We always treat the cursor image size as CSS pixels (and upscale it to device
pixels in HiDPI). We have bugs to stop doing that though (bug 1425694).
Differential Revision: https://phabricator.services.mozilla.com/D18671
--HG--
extra : moz-landing-system : lando
The only reason it was on style_traits is so that they could use it from some
other crates, but Servo eventually ends up getting the value from an integer, so
may as well pass it around and do that in the end of the process anyway.
Differential Revision: https://phabricator.services.mozilla.com/D16557
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.
We should set the 'mGestureDownPoint' correctly when receiving 'touchstart' so that we can
distinguish whether the 'touchend' comes from dragging or simply touching by calling
'IsEventOutsideDragThreshold()'.
Differential Revision: https://phabricator.services.mozilla.com/D11395
--HG--
extra : moz-landing-system : lando
This patch makes EventStateManager handle middle click paste as a default
action.
Unfortunately, we cannot remove the call of HandleMiddleClickPaste() in
EditorEventListener because it's important to consume middle click event
before any elements in the editor. For example, if clicked HTMLEditor has
non-editable <a href> element, middle click event needs to be handled by the
editor rather than contentAreaUtils which handles click events of <a href>
elements. The cause of this kind of issues is, any click event handlers
which handle non-primary button events still listen to "click" events.
Therefore, this patch makes HandleMiddleClickPaste() do nothing if the mouseup
event is fired on an editor.
Differential Revision: https://phabricator.services.mozilla.com/D7855
--HG--
extra : moz-landing-system : lando
EventStateManager needs to handle middle click paste without editor.
Therefore, the handler should be in EventStateManager.
Differential Revision: https://phabricator.services.mozilla.com/D7852
--HG--
extra : moz-landing-system : lando
EventStateManager::InitAndDispatchClickEvent() sends given nsEventStatus to
nsIPresShell::HandleEventWithTarget(). Then, it sends the status to
EventStateManager::PreHandleEvent() before dispatching the event. At this
time, EventStateManager::PreHandleEvent() resets the state to
nsEventStatus_eIgnore. Therefore, for example, if eMouseClick event is
consumed but eMouseAuxClick is ignored, the event status result is
nsEventStatus_eIgnore. So, neither DispatchClickEvents() nor
PostMouseUpEventHandler() cannot check whether at least one click event
is consumed.
This patch makes EventStateManager::InitAndDispatchClickEvent() sends
local variable of nsEventStatus to nsIPresShell::HandleEventWithTarget().
Then, merge the result with current status.
If we'd change nsEventStatus to enum class, we could make this change as
custom "operator|=" or something.
Differential Revision: https://phabricator.services.mozilla.com/D7850
--HG--
extra : moz-landing-system : lando
This patch splits EventStateManager::CheckForAndDispatchClick(). One is for
handling default action of eMouseUp, the other is for dispatching click events.
This makes it easier to add other default actions after dispatching click
events.
Differential Revision: https://phabricator.services.mozilla.com/D7849
--HG--
extra : moz-landing-system : lando
Some methods on Window are not changed because they are part of public
interface. Method names from widget are also unchanged.
Many "full-screen" in comments are also updated to "fullscreen" instead.
Differential Revision: https://phabricator.services.mozilla.com/D5639
--HG--
extra : moz-landing-system : lando
On Android, we don't want touches that are pans/scrolls to gesture activate.
So we don't want to gesture activate on touchstart (analogous to
mouse/pointerdown on desktop) as we can't tell in advance whether a touchstart
will turn into a touchmove. So gesture activate on touchend only if the
touchend does not finish further than the drag threshold away from where the
touch started.
This means we won't gesture activate for touches that turn into scroll
gestures, but we will for touches that are taps.
The tests are disabled on Android, so I don't have a test for this yet.
MozReview-Commit-ID: C8YgAfVqUa7
--HG--
extra : rebase_source : 76380871b1aa2a5e1bb04882104ada75f6bb3f5a
This commit implements the auto-dir scrolling functionality in non-APZ, based on
part 1 to part 3. However, the functionality of mousewheel.autodir.honourroot is
unimplemented in this commit.
MozReview-Commit-ID: 2vYABOx4RkK
--HG--
extra : rebase_source : 7dc45e6747a101c1a2c3a22bc695b2a0b2494b50
This commit only introduces the concept and the functionality of retrieving the
values from the two new related prefs. Still no actual functionality change is
involved.
MozReview-Commit-ID: 2Gl3Wqdo6jL
--HG--
extra : rebase_source : bf30483e3e32829a5d6fd927740471ba348448f9
Do some work in preparation for implementing actual functionalities for this
bug. No actual functionality change is involved in this commit.
MozReview-Commit-ID: 5aLhr38n1N4
--HG--
extra : rebase_source : 15cfc2cea5b7668367dd3bd4a0746ae8c61b7d20
As for now, the scrollable direction with a mouse wheel for a single-line text
control is hard-coded; that is, only horizontal wheel scrolls are able to take
effect while vertical ones aren't. However, this isn't the desired case for
vertical writing mode, where the opposite case definitely suits better.
This commit refines the hard-coded scrollable direction for a single-line text
control to be writing-mode-adaptive.
MozReview-Commit-ID: 4Zkoe2ExPCZ
--HG--
extra : rebase_source : 113b2ea80b6bbbcd2d8379b438de97eedd616551
Andrew Creskey
Sebastian Streich
Daniel Varga
Neil Deakin
Edgar Chen
Paul Zuehlcke
Masayuki Nakano
Ryan Hunt
Sylvestre Ledru
Emilio Cobos Álvarez
Boris Zbarsky
Johann Hofmann
Tooru Fujisawa
Andrea Marchesini
Olli Pettay
alwu
Xidorn Quan
Brindusan Cristian
Chris Pearce
Botond Ballo
Zhang Junzhi