This patch adds test cases for testing favicons of allTabs menu in terms of originAttributes.
It adds tests in existing tests, browser_favicon_userContextId.js and browser_favicon_firstParty.js.
The test will open tabs with different originAttributes and trigger the popup of
allTabs menu. Then it will verify that whether the network requests of favicon
have correct originAttributes.
MozReview-Commit-ID: 4Aa7RDFdosA
--HG--
extra : rebase_source : 407c1c356387f9f05e2fca37cd74339521f2d2f2
This patch adds test cases for testing favicons of allTabs menu in terms of originAttributes.
It adds tests in existing tests, browser_favicon_userContextId.js and browser_favicon_firstParty.js.
The test will open tabs with different originAttributes and trigger the popup of
allTabs menu. Then it will verify that whether the network requests of favicon
have correct originAttributes.
MozReview-Commit-ID: 4Aa7RDFdosA
--HG--
extra : rebase_source : d5fb724ca194d895a78cce5d035008adebcc23ca
The triggeringPrincipal needs to be consistent with the given userContextId.
MozReview-Commit-ID: Ao4hokoIcLb
--HG--
extra : rebase_source : b342a8020960e7e1028c0230ebfc0daf41c60d43
Activity-stream is only enabled in Nightly, and if activity-stream is not
enabled, about:newtab is loaded without the flag
nsIAboutModule::URI_SAFE_FOR_UNTRUSTED_CONTENT, so it will be loaded with
System Principal.
Update the test to verify about:newtab should have firstPartyDomain set
when we enable the pref.
We split about:newtab from browser_firstPartyIsolation_aboutPages.js because
about:newtab needs special care.
In the original test browser_firstPartyIsolation_aboutPages.js, when calling
tabbrowser.addTab, if it found out the uri is about:newtab, it will use
the preloaded browser, however the preloaded browser is loaded before when we
turn on the firstPartyIsolation pref, which won't have the pref set.
To prevent to use the preloaded browser, a simple trick is open a window
first.
The original bug component of this folder is Firefox::OriginAttributes, which
doesn't exist. The Core::DOM:Security fits a proper role at here. Therefore, we
change the bug component into Core::DOM:Security.
MozReview-Commit-ID: 4m9iZ7ofYXN
A web page could generate an URL by URl.createObjectURL(new Blob(...));
then navigate to this generated URL.
In this case the (top-level) document URI will be blob:{origin}:{uuid}.
And we try to add firstPartyDomain on this top-level document with blob URI, so
the following request from this document could have correct origin
attributes.
In the past we used a fixed value for the firstPartyDomain of
NullPrincipal, now we derive it from the path of NullPrincipal, so it
will be unique everytime we create it.
This reduces the amount of places where we need to specify the mozilla/frame-script environment. It does have
the side effect of allowing those globals in the whole file, but that is what specifying the environment would
do, and this is also for mochitest test files only.
MozReview-Commit-ID: 1LLFbn6fFJR
--HG--
extra : rebase_source : 82a6934d90bbbbd25f91b7b06bf4f9354e38865a
When we load about:blank in a remote tab, it will have
LOAD_FLAGS_DISALLOW_INHERIT_PRINCIPAL flag set, which will make
NullPrinicipal as its document principal. So we add
NULL_PRINCIPAL_FIRST_PARTY_DOMAIN as its firstPartyDomain.
So when we load data:, or javascript: URI in a remote tab, it will inherit the
principal from about:blank, hence also inherit the origin attributes.
There are also some about: pages will use codebase principal, so we also
set ABOUT_URI_FIRST_PARTY_DOMAIN as firstPartyDomain on their
principals.
This patch is generated by the following sed script:
find . ! -wholename '*/.hg*' -type f \( -iname '*.html' -o -iname '*.xhtml' -o -iname '*.xul' -o -iname '*.js' \) -exec sed -i -e 's/\(\(text\|application\)\/javascript\);version=1.[0-9]/\1/g' {} \;
MozReview-Commit-ID: AzhtdwJwVNg
--HG--
extra : rebase_source : e8f90249454c0779d926f87777f457352961748d
