The reason why the global ScrollGeneration::sCounter doesn't work for the APZ
case is the APZ sampler thread is per our top level browser window, so if
there are multiple browser windows at the same time, the sCounter will be muted
from different sampler threads.
Differential Revision: https://phabricator.services.mozilla.com/D133439
Depends on D134832
Note: many conformance tests for Array built-ins will need to be
duplicated to work for the equivalent Tuple built-ins eventually; this
commit only includes some of those tests.
Differential Revision: https://phabricator.services.mozilla.com/D134834
* unbox() now returns a TupleType&
* maybeUnbox() now returns a Maybe<TupleType&>; in both cases, callers are responsible for rooting
* IsTuple() now takes a Value& rather than a HandleValue
* ThisTupleValue() now takes a Value& and returns a TupleType&
These changes are meant to minimize assumptions made by TupleObject and TupleType methods about their inputs, and shift responsibility for rooting onto the callers.
Differential Revision: https://phabricator.services.mozilla.com/D135016
Guard `Toolbox#updateFrameButton` with `isDestroying` so the call to `this.target`
later in `_commandIsVisible` doesn't throw because `this.commands` is null.
Differential Revision: https://phabricator.services.mozilla.com/D136713
The old behavior (only send attestation, if attestation-type was "direct" and "none" otherwise) broke the spec.
Only send "none", if directly requested by RP or the user.
Differential Revision: https://phabricator.services.mozilla.com/D132700
Instead of waiting a set time guessed from how long the parent process took to do its work, after a short time the parent process requests progress updates from all still-pending child processes, and restarts the timer if any progress was made.
If processes become unresponsive, they will be the last ones pending, and after one timer cycle without any progress anywhere, the parent process won't wait for children anymore, and will output all profiles successfully gathered so far.
Added `MOZ_LOG=prof` logging in nsProfiler.cpp, to monitor profile-gathering. (And removed a spurious 'd' character in the `LOG` macro.)
Differential Revision: https://phabricator.services.mozilla.com/D135488
This code will be used again in the following patch.
Instead of destroying and re-creating a new timer, we can re-initialize the existing one.
Also add the timer name "nsProfilerGatheringTimer" when first creating it.
Differential Revision: https://phabricator.services.mozilla.com/D135487
This helper function in ProfilerParent sends a progress request to a child process. If successfully sent, the response will resolve the returned promise.
Differential Revision: https://phabricator.services.mozilla.com/D135486
A new IPC function allows the parent process to request a progress update from any child process.
If a profile generation is in progress, the shared `ProportionValue` can be atomically read and sent back in response.
Differential Revision: https://phabricator.services.mozilla.com/D135485
In order to keep the child process responsive to profile IPCs, the heavy work of generating the profile JSON is now done in a separate thread.
A `ProgressLogger` is used to keep track of the progress of this work, and the progress value is stored in a shared atomic `ProportionValue`.
When the JSON profile is ready, the final shmem allocation (used to send the profile to the parent process) is done on the original "ProfilerChild" IPC thread.
Differential Revision: https://phabricator.services.mozilla.com/D135484
The main goal is to separate the profile generation (in a JSONWriter) from the final allocation needed to output the profile in one block.
This will be needed in the next patch, where the profile generation will be done in a new worker thread, but the shmem allocation *must* be done on the original "ProfilerChild" thread that handles IPC responses.
Differential Revision: https://phabricator.services.mozilla.com/D135483
Instead of just waiting for a certain number of profiles, the parent process now waits for profiles from a predetermined list of child process ids.
When receiving a profile, or when something goes wrong with a child process, the corresponding listed id can be removed, until the list is empty.
In a later patch, this list will be used to request progress updates from slow processes.
Differential Revision: https://phabricator.services.mozilla.com/D135482
This will be useful to tie profiles to the child process id that generated them. (At the moment, the parent waits for a number of profiles, but doesn't check where received profiles actually come from.)
Differential Revision: https://phabricator.services.mozilla.com/D135481
A small optimization while working on nearby code, so avoid multiple allocations when we already know how much memory we really need.
Differential Revision: https://phabricator.services.mozilla.com/D135480
Add `ProgressLogger` parameter to most JSON-generating functions.
Each function can update the given `ProgressLogger` between 0% and 100%, and create sub-loggers when calling functions.
The main goal of this instrumentation is to notice when any progress is made by child processes (when the parent process is gathering profiles), so it needs to go deep enough so that it is not stuck on a progress value for "too long" -- During development, that meant progress was always happening when observed every 10ms; In later patches, the overall timeout for no-progress-made will be at least 1 second.
Differential Revision: https://phabricator.services.mozilla.com/D135479
Class storing a value between 0 and 1, effectively 0% to 100%.
It will be used through a ProgressLogger object to track the progress of JSON profile generation (see following patches).
Differential Revision: https://phabricator.services.mozilla.com/D135477
JavaScript code coverage is eagerly parsing all functions ahead of time, which
conflict with the configuration required for testing the eager delazification.
This patch disables the test case if JavaScript code coverage is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D137277
This patch introduce a new test helper to more easily test a page that reloads with an updated content.
This especially take care of source map support.
Differential Revision: https://phabricator.services.mozilla.com/D137162
The Nightly experiment's description:
> Firefox 100 User-Agent String
>
> Make Nightly send websites a User-Agent string that pretends to be Firefox
> version 100. Use this setting to test whether websites will break when
> Nightly hits a three-digit version number. The real Firefox 100 is scheduled
> to be released in May 2022, so start testing your websites now!
Firefox's User-Agent string says "Firefox/100.0" in both release and pre-release channels. Firefox 100's release date will be 2022-05-03. The Nightly 100 development cycle will begin 2022-03-08.
Chrome has a similar chrome://flags/#force-major-version-to-100 flag for testing a Chrome 100 UA.
Differential Revision: https://phabricator.services.mozilla.com/D135316
