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
We used to check if the passed query looked like a tag name so we could
bail out early, as we'd get those results from _searchIndex.
But InspectorUtils.isCustomElementName does match some legitimate
selectors, like div.a-b.
Let's remove the check on custom element and trigger the search in such case.
Original Revision: https://phabricator.services.mozilla.com/D259783
Differential Revision: https://phabricator.services.mozilla.com/D260238
`TypeToString` defines instances for all the numbered int types (like
`int32_t`); unfortunately this can leave some of the named types (like
`int`) out of the sequence depending on how the C headers define the
numbered ones. There are additional instances for signed and unsigned
long, which are needed on some platforms and would break the build on
others; there is an `#ifdef` which attempts to handle that, but the
result of all this is that CI can build for 32-bit x86 Linux but it
fails when I try locally.
This patch simplifies things and removes the `#ifdef` using a similar
idea to bug 836438: the unspecialized `TypeToString` calls another
function with its own set of specializations, with numbered types in the
first layer and named types in the second.
It seems that `nsIFrame::GetLastLeaf()` and `nsIFrame::GetFirstLeaf()`
were designed for helper methods of `nsIFrame::IsVisuallyAtLineEdge()`
and `nsIFrame::IsLogicallyAtLineEdge()`. Therefore, they require the
`nsTextFrame` which is generated by `::before` or `::after` to check
whether the frame is first or last of the line. However, only
`nsIFrame::GetLastLeaf()` is used by `GetNextPrevLineBlockFrame()` too
and I changed the behavior only for `GetNextPrevLineBlockFrame()` in
D216371. Then, that broke the `nsIFrame::IsVisuallyAtLineEdge()` and
`nsIFrame::IsLogicallyAtLineEdge()`. Therefore, this patch moves the
new check to the caller side, i.e., into `GetNextPrevLineBlockFrame()`.
Differential Revision: https://phabricator.services.mozilla.com/D256211
