Use `GetFileType(HANDLE)` on Windows.
Unlike `HandleToFilename`, `GetFileType` is fast enough that we don't need to use a `SmallArrayLRUCache` for it.
The pipe I/Os should not be visible anymore in the startup tests.
Differential Revision: https://phabricator.services.mozilla.com/D82303
Caching filenames in 32-entry LRU array covers >95% of calls, and makes the average `Filename()` call 5 to 10 times cheaper.
browser_start_content_mainthreadio.js needed to be updated to handle operations that now have a filename thanks to the cache.
Since `ClearPoisonIOInterposer()` is never called (see bug 1647107), during Firefox shutdown we put LRUCache in a shutdown mode, which bypasses the cache in case it is still used at that time.
Differential Revision: https://phabricator.services.mozilla.com/D79767
ts_paint depends on the first MozAfterPaint in the content window, not in the
browser as I had thought. After MozAfterPaint, it pings the parent process and
waits for a response (see `TalosPowers.loadPromise`), and then it ends. It will
wait up to 500ms for the response before timing out. Source:
https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/startup_test/tspaint_test.html
At first I modified UrlbarProviderSearchTips to wait on
`browser-delayed-startup-finished`, but the jsm kept appearing in ts_paint
profiles, and that's how I found out the above. So that's not sufficient.
There's already a promise in browser.js for waiting on the first paint in the
first content window, but it's "private." I added a public getter for it and
changed the name so it's clearer that it's related to the first content window,
not the browser window.
I also added a 500ms timeout just like the worst case in ts_paint.
Both checks (paint and the timeout) are done for a particular browser window
only the first time UrlbarProviderSearchTips sees it.
Finally, UrlbarProviderSearchTips can avoid importing BrowserWindowTracker
during startup by having browser.js pass the window to its `onLocationChange`. I
saw the BrowserWindowTracker.jsm import in some profiles while working on this.
With these changes, UrlbarProviderSearchTips no longer appears in ts_paint
profiles when I run it locally -- except when it is imported by
UrlbarProvidersManager, which ultimately happens due to setting the placeholder
text in the urlbar input. But even that doesn't appear in every profile.
I've also included the reordering of checks from a previous version of this
patch. That's still worth doing in general even if it's no longer relevant to
ts_paint.
Differential Revision: https://phabricator.services.mozilla.com/D80799
Rather than sending the strings down to the content process and back up instead
have the content process just send the media type which when prefixed with
`media-` gives us the fluent ID for the string. Ideally this would allow us to
just set that as the `data-l10n-id` for the items but since this tree is
generated by a custom `nsITreeView` implementation that isn't an option so this
still caches the strings on load.
A single formatValues call will be more performant.
Differential Revision: https://phabricator.services.mozilla.com/D77897
Most of TelemetryController is only used in the parent process, but is
currently loaded in all processes, where it needlessly consumes tens of KB of
memory. This patch splits the parent- and content-specific parts, and only
loads each in the processes where they're needed.
Differential Revision: https://phabricator.services.mozilla.com/D79870
Most of TelemetryController is only used in the parent process, but is
currently loaded in all processes, where it needlessly consumes tens of KB of
memory. This patch splits the parent- and content-specific parts, and only
loads each in the processes where they're needed.
Differential Revision: https://phabricator.services.mozilla.com/D79870
Most of TelemetryController is only used in the parent process, but is
currently loaded in all processes, where it needlessly consumes tens of KB of
memory. This patch splits the parent- and content-specific parts, and only
loads each in the processes where they're needed.
Differential Revision: https://phabricator.services.mozilla.com/D79870
The timeout happens when we get an old element of the 'errorCode'
element in the test code. In this patch, we fix this issue by getting
the element every time we check the condition of the 'errorCode'
condition.
Differential Revision: https://phabricator.services.mozilla.com/D80214
Bug 1636207 updated webrtcUI.getActiveStreams to support getting window streams. This updates
the call sites in the legacy webrtc indicator, so we get all streams. In the affected call sites
the streams are used to find and focus the parent window and show the permissions doorhanger.
Differential Revision: https://phabricator.services.mozilla.com/D80030
Caching filenames in 32-entry LRU array covers >95% of calls, and makes the average `Filename()` call 5 to 10 times cheaper.
browser_start_content_mainthreadio.js needed to be updated to handle operations that now have a filename thanks to the cache.
Differential Revision: https://phabricator.services.mozilla.com/D79767
This adds a `browserId` property to all browsing contexts. This ID is the same
for the entire tree of contexts inside a frame element. Each new top-level
context created for a given frame also inherits this ID. This allows identifying
the frame element for a given browsing context.
Originally authored by :mossop in D56245.
Differential Revision: https://phabricator.services.mozilla.com/D77911
This adds a `browserId` property to all browsing contexts. This ID is the same
for the entire tree of contexts inside a frame element. Each new top-level
context created for a given frame also inherits this ID. This allows identifying
the frame element for a given browsing context.
Originally authored by :mossop in D56245.
Differential Revision: https://phabricator.services.mozilla.com/D77911
This removes the diagnostic warnings which used to be logged when the
Large-Allocation header was present, but failed to switch into a
Large-Allocation process. Due to the low adoption of the header, this shouldn't
be too large of a problem, but we can look into re-adding the diagnostics if
needed in the future.
The new codepath no longer performs multiple network requests for
Large-Allocation resources, and now relies on the battle-tested
DocumentLoadListener codepath for process switching.
Differential Revision: https://phabricator.services.mozilla.com/D78998
This pref was enabled on all platforms, and the codepath which has it disabled
has been untested for some time. Remove the pref to simplify the code handling
the old case.
Differential Revision: https://phabricator.services.mozilla.com/D78974
These were only used by process switches triggered via DocumentChannel, which
now take the PROCESS_BEHAVIOR_STANDARD codepath.
Differential Revision: https://phabricator.services.mozilla.com/D78973
As tabbrowser now uses `PROCESS_BEHAVIOR_STANDARD`, `PROCESS_BEHAVIOR_CUSTOM` is
now unused. This patch removes that now-unused code.
Differential Revision: https://phabricator.services.mozilla.com/D78972
Add a series of extra hooks and methods to allow tabbrowser to use the new
process switching codepath. This duplicates some of the logic from
`updateBrowserRemoteness` into event handlers.
Differential Revision: https://phabricator.services.mozilla.com/D78970