HTMLSelectEventListener changes are needed, since currently that code works somewhat by accident given that
mTime often contains totally bogus values, like PR_IntervalNow(). Those changes then reveal issues also in
browser_editAddressDialog.js.
Differential Revision: https://phabricator.services.mozilla.com/D165618
And initialized it only in ctors so that in the next change we can use it to
tell whether this pan event may trigger swipe or not without calling
SwipeTracker::CanTriggerSwipe every time.
There's an unintuitive change in a GTest sending a horizontal pan-start event.
With this changeset, all incomming pan-start events on desktop platforms
basically set mRequiresContentResponseIfCannotScrollHorizontallyInStartDirection
to true even if the event is generated in GTests. So the pan start event runs
into the short circuit path for swipe-to-navigation. This is a good thing because
it means the GTest replicates what our browser does properly.
Differential Revision: https://phabricator.services.mozilla.com/D160435
And initialized it only in ctors so that in the next change we can use it to
tell whether this pan event may trigger swipe or not without calling
SwipeTracker::CanTriggerSwipe every time.
There's an unintuitive change in a GTest sending a horizontal pan-start event.
With this changeset, all incomming pan-start events on desktop platforms
basically set mRequiresContentResponseIfCannotScrollHorizontallyInStartDirection
to true even if the event is generated in GTests. So the pan start event runs
into the short circuit path for swipe-to-navigation. This is a good thing because
it means the GTest replicates what our browser does properly.
Differential Revision: https://phabricator.services.mozilla.com/D160435
This changes makes us match Chrome and Edge.
The default scale is affected by the DPI setting in Windows settings.
I originally included this scale when I wrote this code based on what it seemed like the Chrome code was doing, but I must have misunderstood what the scale they were using represented.
Differential Revision: https://phabricator.services.mozilla.com/D135591
VsyncChild is main thread only, and we would like to reuse PVsync on the
worker threads via PBackgroundChild which already implements it. This
patch does the necessary refactoring to have multiple implementations of
PVsyncChild.
Differential Revision: https://phabricator.services.mozilla.com/D130264
VsyncChild is main thread only, and we would like to reuse PVsync on the
worker threads via PBackgroundChild which already implements it. This
patch does the necessary refactoring to have multiple implementations of
PVsyncChild.
Differential Revision: https://phabricator.services.mozilla.com/D130264
We implement a new nsIDOMWindowUtils function sendNativeTouchpadPan to do this. It is only implemented on Windows here.
Depends on D122048
Differential Revision: https://phabricator.services.mozilla.com/D122049
I'm not sure if the weird dmanip behaviour coming from the OS is new (because we have a new bug (bug 1697091) that seems like dmanip has changed what it sends us sometimes), or has always existed. But it seems like a good idea to make the code robust against this.
We can hit this assert in the following way. It seems as though dmanip decides after the first few OnContentUpdate calls if it is processing a pinch or a pan (because we can get a scale that is slightly different from 1 on the first OnContentUpdated call, but after that point never changes at all while the offset is changing fluidly) and if it decides it is a pan then it locks the scale to whatever it's last value was. So if we get a scale that is very close to 1 but not fuzzy equal to 1 on the first OnContentUpdated call we will decide that we are processing a pinch, but dmanip can then decide that it's processing a pan. Once the user lifts their finger dmanip will inform us via OnViewportStatusChanged that it is now in inertia mode, it is allowed to go into inertia for pans but not pinches because we pass DIRECTMANIPULATION_CONFIGURATION_TRANSLATION_INERTIA but not DIRECTMANIPULATION_CONFIGURATION_SCALING_INERTIA when we create dmanip here https://searchfox.org/mozilla-central/rev/87a8afd9f57ee4bc542ba0ec3f96a891042b6db7/widget/windows/DirectManipulationOwner.cpp#554 And then dmanip can go straight from inertia to running, this causes us to start a new pinch because our current scale is not fuzzy equal to 1. But also, the current scale has not changed, so it is equal to our last scale, so we have no scale change to send in the pinch start event.
An example of logging when it happens is helpful for understanding and can be found at https://bugzilla.mozilla.org/show_bug.cgi?id=1697756#c2
Differential Revision: https://phabricator.services.mozilla.com/D107994
Otherwise we wouldn't send a pinch start. This should never be hit because if we get here the current scale should not be fuzzy equal to the previous scale so SendPinch should compute a non-zero deltaY and send an event and return true.
Differential Revision: https://phabricator.services.mozilla.com/D100170
See bug 1648489 for why we need this.
If we don't send a pinch we don't want to update the last scale so that when we do send an event it incorporates the full scale change from the last time we sent an event.
Even if aScale != mLastScale in SendPinch the computed deltaY ( = 100 * (aScale-mLastScale) * widgetscale) can be 0 seemingly because of floating point weirdness I guess.
Depends on D86495
Differential Revision: https://phabricator.services.mozilla.com/D86496
We do this analogously to how PanGestureInput does it except that the delta's that we compute mLineOrPageDeltaY from are computed by us instead of provided to us.
mLineOrPageDeltaY being non-zero is what EventStateManager::DispatchLegacyMouseScrollEvents uses to decide to send legacy mouse events, so we need to populate it to get those legacy events to send.
This fix is Windows only on purpose as pinches on macOS don't seem to send wheel events (Windows sends ctrl+wheel). When Linux gets implemented it will need to be determined what to do.
Differential Revision: https://phabricator.services.mozilla.com/D86495
The abstract observer base classes are moved to a separate header file
nsRefreshObservers.h and the includes are adjusted accordingly.
Some method implementations are moved to the corresponding implementation files
to avoid the need to include the nsRefreshDriver.h file in the header.
Differential Revision: https://phabricator.services.mozilla.com/D85764
It seems like the build environment needs updating/modifying so it can handle this. But for now we unbreak the build.
Differential Revision: https://phabricator.services.mozilla.com/D74525
We can't just get pinch events, we need to handle both.
This state machine code is basically copied from Chrome's implementation.
Differential Revision: https://phabricator.services.mozilla.com/D71307
We can't just get pinch events, we need to handle both.
This state machine code is basically copied from Chrome's implementation.
Differential Revision: https://phabricator.services.mozilla.com/D71307
Masatoshi Kimura