This reverses bug 1703410: By default the profiler now changes the timer resolution (normally 64Hz) when the requested sampling interval is lower than 10ms, to allow fast-enough sampling for most uses.
But since this can influence other timers in Firefox, it makes debugging some types of issues more difficult. To help with this, there is now a "No Timer Resolution change" on Windows, which prevents the profiler from changing the timer resolution, at a risk of slowing down sampling in some processes.
Differential Revision: https://phabricator.services.mozilla.com/D117626
Don't show the tooltip of the currently open dropdown button
so that the opening of the dropdown popup doesn't look odd.
Differential Revision: https://phabricator.services.mozilla.com/D116956
We had the constant `kMaxEvents` which limits the maximum number of loading
events in `UntrustedModulesData`. Because we had a check for the number of
events in `UntrustedModulesData::AddNewLoads` where we already swapped
`UntrustedModulesProcessor::mUnprocessedModuleLoads` with a local variable,
when the array exceeds `kMaxEvents`, we discarded the remaining loading events.
The proposed fix is to check for `kMaxEvents` before swapping the unprocessed
events, so that the remaining events will be processed the next time.
This was caught by the `UntrustedModulesFixture` GTest. This test had
another test bug that it always expected modules were loaded in the main
thread except the predefined known modules. This is not correct because
the same process may have loaded a bunch of modules in the earlier GTests
such as graphics drivers in different threads. This patch includes a fix
for that bug as well.
Differential Revision: https://phabricator.services.mozilla.com/D117433
The problem in this bug is that the sum of the available spans of child buckets
is not necessarily equal to the available span of the parent bucket. That's
because each child span must be an integer, but a child's ideal span may not be
an integer, so we have to round and an error can accumulate.
This fixes it by detecting that case and then tweaking child spans until their
sum is equal to the parent's available span. If the sum is smaller than the
parent span, then we increment child spans until it's equal; if the sum is
larger than the parent span, then we decrement instead. (The case where the sum
is larger isn't as much of a problem as when it's smaller. We still correctly
limit the total result span due to logic elsewhere, but the bucket's final
result composition may not reflect flex ratios as accurately as it could.)
I added some logic so that the child spans we choose to tweak are the ones that
minimize the mathematical error between the final integer spans and the ideal
unrounded spans. In other words, we pick the best spans possible given that they
must be integers.
We need to do this tweaking when we try to overfill buckets too, not only on the
first pass for a bucket. Currently the second pass is hardcoded in
`_fillBuckets`. Rather than hardcoding the tweaking in both places, I added an
`_updateFlexData` helper method. While I was doing that, I realized we may need
more than two passes per parent bucket in order to optimally fill the children.
So I modified `_fillBuckets` so it recurses with the parent bucket itself when
we need to overfill any of its children.
I also added support for both `availableSpan` and `maxResultCount`. That lets us
get rid of the ugly heuristic special case in `_addResults`. A bucket will be
filled while both its used span and result count are under both these limits.
This also removes support for zero flex. I got really annoyed with it while I
was working on earlier versions of this. It made the code unnecessarily complex.
I added zero flex kind of as a hack to support tail suggestions, but we don't
actually need it at all. We can just move the tail suggestions bucket out of the
main suggestions bucket with form history and remote suggestions.
Finally while I was here I switched from "bucket" to "group" in light of the
renaming in bug 1715484 and bug 1715822.
Differential Revision: https://phabricator.services.mozilla.com/D117582
We kept this class around so that we could toggle back and forth between the
Photon-era footer button style, and the Proton-era menuitem style for footer
buttons.
Now that v89 has shipped, we can remove that class and switch the markup and
styling over completely to the Proton styling.
Differential Revision: https://phabricator.services.mozilla.com/D117553
I removed the part of the test that checks for a history result. That was there to test _filterOnHost, which was removed. See Part 2.
Depends on D116763
Differential Revision: https://phabricator.services.mozilla.com/D116764
I didn't port _filterOnHost, which searches for history from an engine's domain when its alias is typed. It is no longer relevant: a heuristic alias search result puts the user in search mode.
Depends on D116762
Differential Revision: https://phabricator.services.mozilla.com/D116763
We had the constant `kMaxEvents` which limits the maximum number of loading
events in `UntrustedModulesData`. Because we had a check for the number of
events in `UntrustedModulesData::AddNewLoads` where we already swapped
`UntrustedModulesProcessor::mUnprocessedModuleLoads` with a local variable,
when the array exceeds `kMaxEvents`, we discarded the remaining loading events.
The proposed fix is to check for `kMaxEvents` before swapping the unprocessed
events, so that the remaining events will be processed the next time.
This was caught by the `UntrustedModulesFixture` GTest. This test had
another test bug that it always expected modules were loaded in the main
thread except the predefined known modules. This is not correct because
the same process may have loaded a bunch of modules in the earlier GTests
such as graphics drivers in different threads. This patch includes a fix
for that bug as well.
Differential Revision: https://phabricator.services.mozilla.com/D117433
When the default and user branch values of a preference match, the user brach
value is effectively erased, and we keep no evidence that the user made a
choice. This changes makes normandy avoid that situation, so that user
preferences remain intact.
Differential Revision: https://phabricator.services.mozilla.com/D117949
When middle mouse paste is enabled and middle click occurs in an editable
content or it's in a document whose `designMode` is `on`, we shouldn't start
the autoscrolling because the click must be intended for pasting clipboard
content or primary selection to the position.
Differential Revision: https://phabricator.services.mozilla.com/D117987