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
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
getUrlFromAboutReader can return null. There have been crashes caused by not checking this
result in the past. stripAboutReaderFromUrl is a safer version which returns the input URL
if necessary, and is probably what should be used in new code, hence we can make this method
private.
MozReview-Commit-ID: Lg7QWrpSE8F
--HG--
extra : histedit_source : 0964ebab8e9d66e65fc9c3a296031f720219f529
In some of these cases we're duplicating the work of stripAboutReaderUrl. In the other cases
there is no effective difference, however switching to stripAboutReaderUrl allows us
to make getUrlFromAboutReader private, which should help prevent future errors.
MozReview-Commit-ID: BLeQkve2XIs
--HG--
extra : histedit_source : 1818137ef447b70ca49a783a85cb1a198415df77
1. The return value is not used.
2. It should be called only when mSentFirstFrameLoadedEvent is false.
3. Transition to SEEK if there is any pending seek or DECODER_STATE_DECODING otherwise.
MozReview-Commit-ID: LIO0MPGzhsX
--HG--
extra : rebase_source : 591339cf0c239be618ecf25e384baab9c0bb35be
We move the handling of pending seek from the entry action of DECODING to that of DECODING_FIRSTFRAME.
MozReview-Commit-ID: qMnJ0ON2cK
--HG--
extra : rebase_source : d35985d8d66b201a842aea0eeb0650e8ade5cc5b
It is impossible to finish decoding first frames while waiting for data.
MozReview-Commit-ID: 8eR8Rf9TuD8
--HG--
extra : rebase_source : f8d14b294f0518f48f72828b3e9ed5f2b18a3479
