Only return early from PaintFilteredFrame if the scale matrix determinant will
be zero. This should only occur if either the height or width of the context
matrix scale factors are zero.
Depends on D144669
Differential Revision: https://phabricator.services.mozilla.com/D145041
Fix a possible typo, and ensure that both width and height are 1 before
returning from PrescaleAndTileDrawable early.
Depends on D144304
Differential Revision: https://phabricator.services.mozilla.com/D144669
This renames ScaleFactors2D to BaseScaleFactors2D and adds a template
parameter to specify the floating point type to use. This lays the
groudwork for a later patch that will use ScaleFactors2D and
ScaleFactors2DDouble where SizedTyped is used.
Differential Revision: https://phabricator.services.mozilla.com/D144304
That is, treat it as a hint if called before open, and as an override if
called after. Override the hint on open.
This is a less invasive change that is green on try and also fixes the
issue.
Differential Revision: https://phabricator.services.mozilla.com/D145098
Please note that ScaleFactors2D is missing operator*=() for now,
hence the "resolutionToScreen = resolutionToScreen * X" formula.
Differential Revision: https://phabricator.services.mozilla.com/D144883
Currently we record reset telemetry only when the user performs a search. When I
talked with Rebecca today about the part-1 patch, she mentioned we ought to have
a better guarantee about when this telemetry is recorded. Many users don't
perform searches very often, so we may miss out on this telemetry for them.
There are a couple of ways to mitigate it: Record telemetry periodically and on
shutdown, and this patch does both. I chose one hour for the periodic reporting
period, which seems not too long and not too short.
Now that we are recording periodically, I also moved the existing
`_resetElapsedImpressionCounters()` call from when any search starts (in
`startQuery()`) to when suggestions are triggered (in `_canAddSuggestion()`),
which is right before the impression counters are examined to determine if the
suggestion has hit the cap.
So in summary, we'll now record reset telemetry (when necessary) in these cases:
* When the user triggers a suggestion
* Every hour
* On shutdown
Differential Revision: https://phabricator.services.mozilla.com/D145050
This records multiple reset "events" inside a single telemetry event instead of
using one telemetry event per reset event like we currently do. It also stops
recording reset events for interval periods that elapsed while the app wasn't
running. This will prevent us from recording a bunch of events at once like we
currently do. Please see the bug for more background.
A new `eventCount` property in the telemetry event's `extra` indicates the
number of reset events that are being reported in the telemetry event.
I talked with Rebecca about these changes and she's OK with them.
Differential Revision: https://phabricator.services.mozilla.com/D145049
Initially, I thought the bug was related to a missing `extension.id` in
`ExtensionProcessScript.jsm` [1] but that isn't always reproducible.
There is possibly an issue there but I don't think it is the root cause
of the intermittent here (I would think that other OSes would be affected,
which isn't the case according to [2]).
@rpl and I investigated and we noticed that the mochitest error reported
didn't contain a meaningful error:
```
[object Object] - Should not throw any errors
```
Once we fixed the test framework output, we got:
```
FAIL {"operation":"remove","path":"C:\\Users\\William\\AppData\\Local\\Temp\\generated-extension-23.xpi","winLastError":5,"stack":"","fileName":"(unknown module)"} - Should not throw any errors
```
This is why this patch attempts to fix the intermittent by unloading the
extensions first and then removing the tab. As @rpl said:
> That may actually make sense, maybe removing the tab right before the
> unload prevented the extension to coordinate with the child process and
> make sure we flushed the cache, and that process may not have been yet
> fully destroyed.
[1]: https://searchfox.org/mozilla-central/rev/ecd91b104714a8b2584a4c03175be50ccb3a7c67/toolkit/components/extensions/ExtensionProcessScript.jsm#124
[2]: https://treeherder.mozilla.org/intermittent-failures/bugdetails?startday=2022-04-22&endday=2022-04-29&tree=trunk&bug=1761550
Differential Revision: https://phabricator.services.mozilla.com/D145104
I wrote this tutorial while documenting my process of adding a
component. I attempted to figure out the process rather than just cargo
culting from examples. The idea is that you can follow along with this
to get a new component going, and then reference the more detailed
documentation for implementation details.
Differential Revision: https://phabricator.services.mozilla.com/D140262
When accessing the nsIRemoteAgent interface from a content
process the running state cannot be determined without
communicating with the Remote Agent class from the parent
process.
Similar to Marionette this patch adds a dedicated class of
the Remote Agent for content processes, and exports an
instance of the appropriate class depending on in which
process the Remote Agent gets created in.
Differential Revision: https://phabricator.services.mozilla.com/D144983
The "session.new" command currently doesn't work because the
transport is started after sending the command. This needed
to be flipped.
Also it is helpful to have the event loop of the current
transport available as property on the BiDi session directly.
Differential Revision: https://phabricator.services.mozilla.com/D144979
We need to wait for the stream stop called by the forced error
before calling `AudioInputSource::Stop` to ensure the callback order in
the test. Otherwise, the stream stop called by the forced error on the
background thread will race with the stream stop called by the
`AudioInputSource::Stop` in its task thread.
The problem of the intermittently unexpected callbacks can be reproduced
by adding a delay/thread-sleep in the forced-error's background thread
task. When MockCubeb runs into the error state by `ForceError()`, it
will create a background-thread task to stop the cubeb stream. On the
other hand, when `AuidioInputSource::Stop` is called, it will create a
task to stop the cubeb stream first and then destroy the cubeb stream,
on its own task thread. Most of time, when `AudioInputSource::Stop` is
called, the underlying cubeb stream has been stopped by the brackground
task, so the `MockCubebStream` won't fire the stopped-state callback.
`MockCubeb::StopStream` in `MockCubebStream::Stop()` called by
`AudioInputSource::Stop()` will return a `CUBEB_ERROR` in this case
since no stream needs to be stopped, and so no callback need to be
fired.
However, in rare cases, the stream stop on the AudioInputSource's task
thread finishes before the one in the background thread. Hence, the
`MockCubebStream::Stop()` called by `AudioInputSource::Stop()` can stop
the stream successfully and then fire a stopped state callback.
We don't care what thread stop the stream in
`TestAudioInputSource.ErrorCallback` test, as long as the error-state
cabllback can be forwarded correctly and the stream can be destroyed in
the end. To avoid the racy stream stop calls between the background
thread and the task thread, we don't call `AudioInputSource::Stop()`
until stream is stopped in background thread.
Differential Revision: https://phabricator.services.mozilla.com/D144637
This patch also adds assertions for breakpoints on the server to the
breakpoints reload tests. This also asserts that the breakpoint is not removed
on the server when related source no longer exists after a reload
Differential Revision: https://phabricator.services.mozilla.com/D142545
Thread local variables might be doing lazy allocation in our back, so
querying for NS_IsMainThread() within an exception handler would trigger
memory allocation which in turn will deadlock our process.
Differential Revision: https://phabricator.services.mozilla.com/D144954