Before this patch if we failed to launch the crash helper client then we
would either freeze or crash Firefox, which is not what we want. This
makes sure that errors when launching the crash helper are not
catastrophic. Additionally, this problem was triggered on a machine that
launched more than 64 child processes at startup during session restore.
That was a hard limit on Windows because of the limitations of
WaitForMultipleObjects(). I adjusted the code to also handle that
gracefully even though we don't support more than 64 child processes at
the moment. That's not a big deal because we're not yet using that
particular IPC channel, so ignoring every child process above the 63rd
doesn't change anything at the moment. Last but not least there was a
small race in the crash helper rendez-vous that might cause Linux to
attempt to generate a minidump before we had allowed a child process to
allow the crash helper to ptrace() it. This was also fixed.
Original Revision: https://phabricator.services.mozilla.com/D256299
Differential Revision: https://phabricator.services.mozilla.com/D262076
This channel is currently only used on Linux to rendez-vous with the
crash helper, obtain its PID and use it to enable the process to be
dumped when the Yama LSM is enabled. It will be used to actually request
a dump in the future, when the breakpad exception handler is removed.
Original Revision: https://phabricator.services.mozilla.com/D254047
Differential Revision: https://phabricator.services.mozilla.com/D262074
This is the second step towards daemonizing the crash helper process. The code
used to listen to incoming connections and messages is moved directly into the
server for better coupling. New and existing connections are now categorized
as belonging to Firefox parent process, a child process or an external process
(typically the WER service on Windows). The permission checks on the various
messages are now based on these categories, instead of the PIDs of the
crash helper clients.
Original Revision: https://phabricator.services.mozilla.com/D251559
Differential Revision: https://phabricator.services.mozilla.com/D262070
This paves the way for the daemonization of the crash helper. First of all the
main process won't know the PID of the crash helper process directly, as it
won't be a child of the main process anymore. Additionally, child processes'
IPC channels will be created in the main process, and then both ends will be
handed to the crash helper and child respectively. Because of this it won't be
possible for a child to fetch the PID of the other endpoint of the pipe (all
operating systems record the process identifier of the process that *created*
the pipe as the endpoint, regardless of what process one endpoint is handed
to afterwards).
This patch removes all references to the crash helper PID and ways to fetch it
from the crash helper IPC machinery. See the following patches for how we
deal with authorizing certain operations now that we don't have the PIDs
anymore.
Original Revision: https://phabricator.services.mozilla.com/D251558
Differential Revision: https://phabricator.services.mozilla.com/D262069
Root Cause:
The issue was caused by cookie headers being copied twice. Cookies were added to the revalidating channel just before it was opened, in PerformBackgroundCacheRevalidationNow -> VisitNonDefaultRequestHeaders, and then again in PrepareToConnect -> AddCookiesToRequest, where cookies from the cookie service were merged with those passed during channel creation. This led to duplicate cookies being sent.
Fix:
We now skip setting cookies if the channel is for cache revalidation. This is because, at the point of opening, the channel already includes both the user’s cookies and those from the cookie service. The fix is based on the assumption that by the time PerformBackgroundCacheRevalidationNow is called, cookies are already up-to-date in mRequestHead. This assumption is valid, as cookies are added in PrepareToConnect, which is always invoked before OpenCacheEntry.
Differential Revision: https://phabricator.services.mozilla.com/D260268
I wasn't around when RFPTarget::SiteSpecificZoom was implemented, but the current implementation is very confusing.
In Firefox, we have two modes of zoom level. Per tab zoom, and site specific zoom. It is controlled in two (maybe more) places. browser-fullZoom.js and in [CanonicalBrowsingContext.cpp](https://searchfox.org/mozilla-central/rev/ac81a39dfe0663eb40a34c7c36d89e34be29cb20/docshell/base/CanonicalBrowsingContext.cpp#285-289).
Our current implementation disables site specific zoom in `browser-fullZoom.js` by checking the RFP target, but it doesn't modify `CanonicalBrowsingContext.cpp`. So,`CanonicalBrowsingContext` still thinks we are using site specific zoom.
Pre-bug1914149 this method worked because we didn't keep/inherit zoom level across navigations. Post-bug1914149, it no longer works because we keep the zoom level across navigations in `CanonicalBrowsingContext` and let `browser-fullZoom.js` reset to its correct value back.
The issue is caused because `CanonicalBrowsingContext` keeps the previous page's zoom level, but `browser-fullZoom.js` thinks we use tab zoom mode, so it doesn't bother setting the zoom level for the site/page. So, we end up keeping the zoom level.
The solution here I'm suggesting is, doing the opposite of what we are doing in `browser-fullZoom.js`. So, now we should force SiteSpecificZoom with RFP. The reason I'm suggesting this is because within the same site, even acrss tabs, we persist cookies, so fingerprinting isn't much of concern here. We also don't persist zoom levels in private browsing. So, linking normal to PBM isn't a concern either.
So, in summary,
- If you open the same site, in 100 tabs, all of them will get the same zoom level with this patch (just like default normal Firefox)
- If you are in PBM, the zoom level is NOT persisted.
- If you are in normal browsing, the zoom level is persisted, but so are cookies.
Original Revision: https://phabricator.services.mozilla.com/D257497
Differential Revision: https://phabricator.services.mozilla.com/D261948
In D246824 we moved the `l10n-central` clone step out of `l10n.mk`.
We added it to the code path for the `package-multi-locale` command,
but we did not add it to `build installers-$AB_CD` command.
This made single locale repacks not download the `l10n-central` repo
and single locales silently run without actuall doing localizations.
Original Revision: https://phabricator.services.mozilla.com/D258311
Differential Revision: https://phabricator.services.mozilla.com/D261995
This removes test_searchConfig_google_with_pref_param because the Nimbus test is enough to cover it - we should only
be setting those params via Nimbus. We also have test_getSubmission_params_pref* which cover the preference scenario
in non-'live' configuration conditions.
We rework the Nimbus test to only apply to non-ESR, and adds specific skip-if conditions. We also add a test for
ensuring that the channel is always the correct value on ESR (even if no enterprise policy is set).
Original Revision: https://phabricator.services.mozilla.com/D261528
Differential Revision: https://phabricator.services.mozilla.com/D261588
Bug 1902315 removed a PlaceBehind call here, which in this case happened
to also activate the window (via the aActivate = true parameter).
Keep raising the window manually, but with simpler APIs.
Differential Revision: https://phabricator.services.mozilla.com/D258743
If the inspector was opened from the Inspect context menu, the node gets selected
in the MarkupView constructor, but the Toolbox focuses the Inspector iframe once
the tool is loaded (and the iframe is actually visible), so we need to focus
the selected node after the inspector was properly selected and focused.
Original Revision: https://phabricator.services.mozilla.com/D259039
Differential Revision: https://phabricator.services.mozilla.com/D260236
