Before this patch, we consider credit card sections with only one cc-number
field to be valid sections ONLY IF its cc-number field has
"autocomplete=cc-number". In other words, if we infer the field is
a cc-number field because of our detection heuristic, the section
is considered to be invalid.
In this patch, we remove the "autocomplete=cc-number" constrain, which
means as long as a credit card section has a cc-number field, it is a
valid cc section.
Differential Revision: https://phabricator.services.mozilla.com/D151806
We directly pass the editor stylesheet in the `location` parameter that is passed
to `jumpToLocation`.
`jumpToLocation` wasn't covered in any test, so we modify `browser_styleeditor_media_sidebar.js`
to add coverage for it.
This is also testing Bug 1779180 which is in the same stack.
Differential Revision: https://phabricator.services.mozilla.com/D151597
For <style> elements, `getRelativeRuleLine` gives us the position of the rule
inside a stylesheet, when `getRuleLine` gives the position of the rule relatively
to the whole HTML source.
The former is more accurate for us when we want to display such line number in
DevTools UI (for example in the StyleEditor media query sidebar).
Test will be added in next patch of this queue.
Differential Revision: https://phabricator.services.mozilla.com/D151596
There are potential races between insertion of the same gradient into
the cache on different threads, as well as acquiring a strong reference
to the GradientStops object racing with the expiration timer.
Differential Revision: https://phabricator.services.mozilla.com/D151981
So, the problem was just that in LoadNativeMenus, we do our cleanup of the
sLoadNativeMenusListeners list. However, we were also early exiting from that
function if we're in headless mode. We have no good reason to be in that
function to begin with if we're in headless mode though, so I just hoisted
the check out to an earlier point.
Differential Revision: https://phabricator.services.mozilla.com/D151929
be -> b947d6043de94b612e4e95dc566324f077a1c6e7
eu -> 41027f34281a8b2676601d54b744d2a9b666ebb0
ja -> 60eb149d13041af5264fec3fd77922dc57b280c9
ja-JP-mac -> 6f101bafd6b7ef1f46ba63af22cd3118ba19a879
uk -> 9ff132a30b7c1446984004546a85c55fb90c7bb8
Instead of using the public member type `PrivateIPDLCaller` to
restrict access to certain `Shmem` member functions, make them
`private`, and designated `IProtocol` and `ITopLevelProtocol` as
friends of `Shmem`.
Differential Revision: https://phabricator.services.mozilla.com/D151952
With this fix changing the Colorway theme should automatically update the Colorway CTA in Firefox View. Additionally, the Colorways portion of firefoxview.mjs has been migrated to colorways-card.mjs and restructured to match the style of the rest of the Firefox View codebase.
Differential Revision: https://phabricator.services.mozilla.com/D150878
When the session storage prefs are enabled, GeckoSession updateSessionState will provide the bundle of information, including zoom, scroll, and form data, to the delegate. Currently works for Fission and on Fenix.
Differential Revision: https://phabricator.services.mozilla.com/D148215
UserAgent() needs a parameter because it previously was
calling the non-fine-grained RFP check. It can't call the
fine-grained check, so it needs to be told what to do.
AddStandardRequestHeaders calls UserAgent() and needs to
know what to pass it.
Differential Revision: https://phabricator.services.mozilla.com/D144582
We change it from taking bool aIsCallerChrome to
Maybe<bool> aShouldResistFingerprinting. If there is
a value in there, it is used for determining RFP status.
If not, we call ShouldRFP with the provided Document.
This is needed because on a Worker, we wind up in UserAgent
with no Document, we need to pass the RFP decision in
from WorkerPrivate.
Differential Revision: https://phabricator.services.mozilla.com/D144581
Everywhere except one loadInfo is supplied to an HTTPChannel
right after it is Init()-ed. Inside of Init we would like to
use the loadInfo so we'll put it in there.
Differential Revision: https://phabricator.services.mozilla.com/D144580
Whereas previously we would pass in the principal of a document,
now we will pass in the document directly. This will work for most use
cases, but not all (like Workers.)
Additionally, for the User Agent, if we do not Resist Fingerprinting
(because there is an exemption), we will fall through to getting the
User-Agent header which uses the coarse RFP check, so we fix that in
a later patch.
Differential Revision: https://phabricator.services.mozilla.com/D138778
Previously, this test would open a page and then enable/disable
RFP while the tab was open, writing and reading the canvas as
it went.
Now that CookieJarSettings gets initialized when a document loads
and stays constant for the lifetime of the document, we cannot enable
and disable the prefs and expect them to continue to behave correctly.
We do a 'pre-test' to populate a canvas and then get the true image
data for it. Then we set the preferences prior to loading future
documents and compare the extracted canvas data to the known-correct
data to see if we are correctly spoofing it or not.
Differential Revision: https://phabricator.services.mozilla.com/D150592
- Move ShouldRFP(char*), ShouldRFP(docshell), ShouldRFP(Document)
below some utility code.
- Now that we know we should check the CookieJarSettings, using
ShouldRFP(nsIPrincipal) is dangerous. We mark it as dangerous
and annotate the existing uses of it.
- At the same time, an nsILoadInfo has the CookieJarSettings we
want to check, so create a ShouldRFP(nsILoadInfo) that checks
it and cascades to the (marked-dangerous-but-not-dangerous-for-
this-call) principal function.
- We also correct a situation where WorkerLoadInfo does not
initialize the shouldRFP member.
Differential Revision: https://phabricator.services.mozilla.com/D150591
Previously, we initialized WorkerLoadInfo's shouldRFP member
using the Worker's principal at time of construction. It is
better to populate it from the RemoteWorkerData structure.
The RemoteWorkerData's shouldRFP member can be initialized
with the correct context.
In ServiceWorkerPrivateImpl.cpp it has the same effect, before
and after we use ServiceWorkerInfo.mPrincipal
But for SharedWorker.cpp we previously used
RemoteWorkerData.principalInfo (the second of three principal
members). This was initialized from the WorkerLoadInfo.mPrincipal
member, which in turn came from loadInfo.mChannel which in turn
came from loadInfo.mLoadingPrincipal.
Now we use the WorkerLoadInfo.mShouldResistFingerprinting member
which is initialized from
nsContentUtils::ShouldResistFingerprinting(document) in
WorkerPrivate::GetLoadInfo which can take into account greater
context which will be important in the next few patches.
Differential Revision: https://phabricator.services.mozilla.com/D150590
Now that the ShouldRFP member is correctly populated (we hope)
in CookieJarSettings, we can use it in our ShouldRFP methods.
There are two general scenarios:
An exempted domain frames a non-exempted domain.
The inner frame should be non-exempted.
A non-exempted domain frames an exempted domain
The inner frame should be non-exempted.
In the first scenario, CookieJarSettings.shouldRFP member
will be false (exempted.) We clearly cannot blindly rely
on the member, it would be wrong here.
In the second scenario, CookieJarSettings.shouldRFP member
will be true (non-exempted). This is the scenario we really
need CookieJarSettings for.
----
We take the opportunity to add an additional check for the
'exempted domain framed by a non-exempted domain' scenario.
This additional check takes advantage of the first party
isolation key (for FPI) or partition key (for dFPI).
Differential Revision: https://phabricator.services.mozilla.com/D150589
CookieJarSettings frequently gets populated in a place
where we have ready access to the Document/Channel it
is being constructed for. This lets us populate the boolean
and pass it into CookieJarSetting's constructor easily.
When it is created for LoadInfo, we need to plumb the URI
through by adding it to LoadInfo::CreateForDocument.
Differential Revision: https://phabricator.services.mozilla.com/D150588
Before we took a very simplistic view to domain-based RFP
exemptions - if the loading principal said an exempted
domain, you were exempted.
This did not intelligently take into account iframes. In
particular, if a non-exempted domain framed an exempted
domain, the exempted domain's iframe would be exempted.
It probably should not. This is debatable, but at this
point in time after consultation with Tor we are going
to take the approach described in the comments in
CookieJarSettings.h
Notably this is creating a gap when it comes to nested
iframes. If an exempted domain iframes a non-exempted
domain, which in turn iframes an exempted domain - the
innermost iframe will be exempted even though its parent
is not. This is not ideal, once a document is non-
exempted, all children should be non-exempted. But this
is especially difficult to implement with the facilities
easily available to us, so we leave this corner case for
another day.
Differential Revision: https://phabricator.services.mozilla.com/D150587
