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
be -> 60d014645ea3099a4f5af8656554d50b7df86de4
fi -> d60e530d98c8b7ca842316ea332a13e0bb5f7230
lv -> cdda11922d7dd66ec143b81c4ef959c7371aa5f0
sk -> 84770a640af927fcbeb544a09071b04035f1e15e
tr -> e05793f641ad8a7bae759559a9bb94c66213d7b7
uk -> 75d2899b19cd32e83507b6e6cf78fe4eae509671
vi -> 99afa839735f427184bc447c79778c1a80fd1373
This can cause an issue where removing a state looks as though it didn't
invalidate, because the internal representation contains multiple copies
of the same state ident.
Differential Revision: https://phabricator.services.mozilla.com/D205518
Explicitly committed transactions are aborted in case of a failed request. This
is achieved by tracking order of requests. The order of requests is currently
tracked by storing request serial numbers. However, request serial numbers are
not always in sync between parent and child, so they are only suitable for
logging purposes. This patch switches from request serial numbers to request
ids which are only generated by the child side and thus always in sync between
parent and child.
Differential Revision: https://phabricator.services.mozilla.com/D204200
