Content intent of completed DownloadNotification now uses a PendingIntent which launches an Activity directly.
Previously, we launched the Activity indirectly from a BroadcastReceiver, which is less performant and is prohibited by the OS since Android 12.
The download notification test has been modified to mock out the file opening behaviour, as this test is just checking the visuals of the notification rather than the onward journeys.
Add notification trampoline test case that fails before the fix was made & passes after, to cover this bug.
Fix lint errors + add trailing comma to keep linter happy
Differential Revision: https://phabricator.services.mozilla.com/D205042
The plan is to replace the implementations of these functions with an
ICU4X/Rust back end and then make the XPCOM versions call into these.
Migrating existing C++ callers is out of scope for this changeset.
Differential Revision: https://phabricator.services.mozilla.com/D205420
NOTE: The main part of this change is the call site of
NotifyAPZStateChange(eStartTouch) in AsyncPanZoomController::OnTouchStart.
Other parts are just renaming.
Differential Revision: https://phabricator.services.mozilla.com/D204705
On environments where double-tap-to-zoom is allowed, we don't immediately send
a single tap event when a touch-end happens, we later send a single tap event
when we are sure that the touch-end is not followed by double-tapping. Thus
when ActiveElementManager got the touch-end notification from an APZC, we need
to differentiate the situation to activate an element when ActiveElementManager
finally got a single tap event. This change introduces a tri-state to differentiate
the situation.
`helper_bug1806400-3.html` in this change is a subset of
`helper_touch_synthesized_mouseevents.html?scrollable=true`.
`helper_bug1806400-4.html` is anocher variant of `helper_bug1806400-2.html`
Differential Revision: https://phabricator.services.mozilla.com/D202384
This fixes a regression in D199027. The regression is that element activation
happened even on double-tapping.
The regression scenario happens on environments where double-tap-zoom is allowed
and where the target APZC is pannable. When the APZC received the first
touch-end event the APZC doesn't send a single tap event immediately. In the
meantime the ActiveElementManager tries to generate a `SetActiveTask` after both
of touch-start event and start touch notification received, but sometimes the
first touch-end event arrives to the ActiveElementManager before the touch-start
event (this case is handled in D199282), thus the CancelTask in
HandleTouchEndEvent() got called first, then a `SetActiveTask` was generated.
Differential Revision: https://phabricator.services.mozilla.com/D204577
There's a race condition where APZStateChange notifications and touch-start
event happen in the following order;
1) APZStateChange::eStartTouch
2) APZStateChange::eEndTouch
3) touch-start event
Thus in 2) `mCanBePanSet ` was reset before using the flag at 3).
Differential Revision: https://phabricator.services.mozilla.com/D199282
`APZStateChange::eEndTouch` notification arrives after `eTouchEnd` event in some
cases, thus in such cases setting `mEndTouchIsClick` only on
`APZStateChange::eEndTouch` notification causes a situation that the previous
`mEndTouchIsClick` is used on the next `eTouchEnd` event.
Also `APZStateChange::eStartTouch` notification and `eTouchStart` event arrive
after either `APZStateChange::eEndTouch` notification arrives after `eTouchEnd`
in some cases.
Differential Revision: https://phabricator.services.mozilla.com/D199025
Similar to the situation between `APZStateChange::eStartTouch` and `eTouchStart` event,
`APZStateChange::eEndTouch` can happen after `eTouchEnd` event.
Differential Revision: https://phabricator.services.mozilla.com/D199026
Aside from being a fundamental part of semantics, this is needed for our tests.
These mappings are based on the Core AAM and HTML AAM specs, plus some personal judgement where Gecko roles weren't covered by these specs.
UIA control types are rather limited and they apparently expect us to expose a lot of things using LocalizedControlType, but that isn't implemented for now.
I expect these will need to be revised in future, but this is a starting point.
Differential Revision: https://phabricator.services.mozilla.com/D205185
This identifies the root of our implementation and allows for focus querying and hit testing.
We also implement IRawElementProviderSimple::get_HostRawElementProvider to connect to UIA's HWND provider.
Differential Revision: https://phabricator.services.mozilla.com/D205182
Our IUnknownImpl macros avoid boilerplate, but they weren't designed to handle the quirky inheritance of our MSAA/UIA implementation.
Among other things, using these macros required us to override AddRef and Release in uiaRawElmProvider, which was a bit confusing.
Rather than perpetuating this weirdness as things get more complex, just implement what we need by hand.
Differential Revision: https://phabricator.services.mozilla.com/D205180
1. Respond to WM_GETOBJECT with our IRawElementProviderSimple implementation for the root Accessible of the HWND.
2. Don't allow QueryInterface to UIA interfaces if the UIA pref is disabled. This stops WM_GETOBJECT from returning our UIA implementation in this case.
3. Specify the appropriate provider options.
Differential Revision: https://phabricator.services.mozilla.com/D205179
