This task was added in D161866 and it fails because sometimes this happens in
the view:
1. The row count is 19 and the last row is not the quick suggest
2. Then the quick suggest row gets added, so the row count is 20
That makes the mutation promise hang because it expects the row count to be 19
when the quick suggest row is added last.
This patch makes the mutation listener wait for the quick suggest row to simply
be added instead of assuming it's the last row during a certain row count. It
also removes some checks that aren't necessary to test the thing this task is
testing and that are also susceptible to races.
[Retriggers on try](https://treeherder.mozilla.org/jobs?repo=try&revision=15b1943e76a08174e4fad28675348e9d12428483) are green.
Differential Revision: https://phabricator.services.mozilla.com/D162479
This prevents running the cookie banner click code for sites which have a rule
with an empty click object. This is important for performance reasons and
prevents us from recording invalid "banner not found" telemetry.
Differential Revision: https://phabricator.services.mozilla.com/D161919
This is done by calling `AddonManagerPrivate.callInstallListeners` when we handle
`SitePermsAddonInstall`'s specific listeners.
We take this as an opportunity to remove support for the `onDownloadEnded` event
as it didn't do anything and isn't something we want to record for SitePermsAddon.
We also set `SitePermsAddonInstall#installId` which is used in `AMTelemetry`.
Assertions on registered telemetry events are added in browser_midi_permission_gated.js,
and a test case is added to ensure cancelling the event from the second popup works
as expected, since it wasn't checked before.
Differential Revision: https://phabricator.services.mozilla.com/D162412
The switch to using `withFirefoxView` caused another onboarding prompt to show. After the fx view tabstrip button has been clicked for the 3rd time we display a new message. This wasn't happening before because the pref that controls this is tied to that button click, so didn't get incremented when we were opening about:firefoxview in a new tab.
Differential Revision: https://phabricator.services.mozilla.com/D162427
This in effect reverts part of bug 1756400, so that we only do the full
per-language fontconfig substitution processing for locales that use
CJK or Arabic script. These are the locales where it is likely that
there may be custom per-language/locale font preferences that need to
be respected.
(In theory fontconfig could be set up with per-language rules even for
distinctions like 'en-US' vs 'en-GB', or 'en' vs 'fr' vs 'de', etc.,
and we will no longer respect these. But it is almost vanishingly unlikely
that separate font mappings for such distinctions will really be needed,
and the cost of doing all the lookups separately for every lang tag,
even within simple writing systems like Latin, is excessive.)
No automated tests, as this is heavily dependent on the system configuration.
Differential Revision: https://phabricator.services.mozilla.com/D162304
it started as a single method new_frame_ready with a composite parameter, to be split into two functions that end up calling the same HandleFrameOneDoc with a composite parameter so the extra function doesn't provide anything.
Differential Revision: https://phabricator.services.mozilla.com/D162299
Only transactions that contain the generate_frame flag are tracked by the pending frame and frame build counters.
This patch attempts to make this clearer with two small adjustments:
Firstly by putting the IncPendingFrameCount call right next to Transaction::GenerateFrame.
Secondly, undoing the hack in wr_notifier_wake_up. The latter is called outside of normal rendered/tracked frames and was calling HandleFrameOneDoc which decrements the rendered frame counter. To compensate it had to manually increment both counters via IncPendingFrameCount and manually decrement the built frame counter via DecPendingFrameBuildCount. Instead this patch introduces the aTrackedFrame argument so that HandleFrameOneDoc only fiddles with the counters when needed and wake_up does not have to hack around it.
Differential Revision: https://phabricator.services.mozilla.com/D162298
mSkippedComposite's purpose is to keep track of the fact that the window is not up to date because the previous composite was skipped. This informs RetrySkippedComposite that a new frame is needed to get the latest changes rendered. As soon as we successfully schedule a composite know that the latest changes are en route to be rendered so we don't need RetrySkippedComposite to push an additional frame later.
Differential Revision: https://phabricator.services.mozilla.com/D162297
The previous name could have related to any situation where a composite is needed such as when animating or receiving transactions, but the function is actually specifically about scheduling a new composite if the previous one was skipped.
Differential Revision: https://phabricator.services.mozilla.com/D162295
- Ensure that the pending frame count is decremented by HandleFrameOneDoc even after some of the rare early-outs.
- Always check TooManyPendingFrames in CompositeToTarget.
It is unclear that these will actually catch (all of) the extraneous skipped frames. If anything, the simplification will make further investigation easier.
Differential Revision: https://phabricator.services.mozilla.com/D162294
