Add an origin attribute called 'firstPartyDomain'.
This value will be extracted from the URL bar.
And the purpose of this attribute is used to isolate the data-jars.
Please see the tor documentation.
https://www.torproject.org/projects/torbrowser/design/#identifier-linkability
The idea is like a superset of 'reject third party cookies', but not
only apply for cookies, it also applies to all data-jars like localStorage,
indexedDB and so on.
So basically an iframe will have its own data-jar, and this data-jar is
isolated by the URL from URL bar, for instance, an iframe
https://facebook.com inside https://cnn.com won't share data-jar with
the iframe (https://facebook.com) in https://bbc.com
When investigating bug 1075194, I found that we don't check return value of DocumentPropertiesW. So we sould use correct type and add log for this API.
MozReview-Commit-ID: Ck3VwMq9OpQ
--HG--
extra : amend_source : a0da15b578055b7612ce96b44cac2cd69607fa51
DiscardRemaning was needed to prevent debug-time assertion that the buffer was
read completely or explicitly discarded.
However this required extra work in cases where buffer didn't need to be read
to the end.
And also it could cause crashes (in debug versions) if a buffer was not fully
read, be it because the parser was incorrect or because the media file itself
was wrong (though possibly still readable despite that).
Finding parser issues is still possible by manually instrumenting ByteReader
during development.
And reading media file with small recoverable errors is a bonus.
MozReview-Commit-ID: 2RUYzaYAeRW
--HG--
extra : rebase_source : 26c41758b1b2c87542bf4e41d08e361198ca5b13
I came across these while working on a different bug that changed the grouping
in the unified build. Adding these as a separate step will hopefully remove a
little noise from the next patch in the series.
MozReview-Commit-ID: Km7wTcVWG9n
--HG--
extra : rebase_source : 0610add67482c1a5aa7c4f576e151ed9437698c0
This mirrors the location of Servo_Init. This is important because xpcshell runs
don't use nsAppRunner, and so we end up with an unpaired call to Servo_Shutdown,
which crashes.
The immediate reason we need to change this is that bug 1299911
proposes adding a verifier to check that there are no black-gray edges
in the JS heap, and sGeneration being 0 causes that to fail, due to
mozilla::dom::TraceBlackJS(). If something is a black root, I believe
the verifier requires that it be marked black. This makes sense,
because a black root is something that is definitely alive, and if the
object is marked gray, the CC might free it, as far as the GC knows.
This fails because when the browser starts, it GCs and marks the stuff
at the bottom of TraceBlackJS grey. Then it runs the CC, which flips
sGeneration to 1. Now, the verifier runs (before the GC runs!), and it
sees that the stuff in TraceBlackJS claims to be black, but is grey,
causing a verification failure.
In this particular case the code is actually safe. The purpose of the
black-gray invariant is to ensure that the CC does not incorrectly
unlink any gray C++ objects that are reachable from black JS
roots. The JS objects in TraceBlackJS should all be reachable directly
from a C++ object, and the CC knows that those C++ objects are alive
(because of refcounting). Therefore, the CC will not unlink any
objects that are reachable from black JS roots.
MozReview-Commit-ID: 8PrRkjqWBL
--HG--
extra : rebase_source : f9c2971bf71475202a1a6bbc719ab9ce19f94bc5
Yoshi Huang
Olli Pettay
Dão Gottwald
Luke Wagner
Cykesiopka
Phil Booth
Jonathan Kew
Stone Shih
Chih-Yi Leu
Till Schneidereit
Kershaw Chang
Yen Chi Hsuan
Sebastian Hengst
Hannes Verschore
Shu-yu Guo
Sotaro Ikeda
Makoto Kato
Robert O'Callahan
Nicholas Nethercote
Ryan VanderMeulen
Gerald Squelart
Brian Birtles
Phil Ringnalda
Zibi Braniecki
Bobby Holley
Andi-Bogdan Postelnicu
Andrew McCreight
Andrzej Hunt