These two interfaces contain nostdcall methods, so they should be marked
builtinclass.
There is a JS implementation of nsIWebNavigation in RemoteWebNavigation,
but it appears to never be passed into C++, so it doesn't need to be
made into a "real" implementation of nsIWebNavigation that can be passed
through XPConnect.
Differential Revision: https://phabricator.services.mozilla.com/D98862
These two interfaces contain nostdcall methods, so they should be marked
builtinclass.
There is a JS implementation of nsIWebNavigation in RemoteWebNavigation,
but it appears to never be passed into C++, so it doesn't need to be
made into a "real" implementation of nsIWebNavigation that can be passed
through XPConnect.
Differential Revision: https://phabricator.services.mozilla.com/D98862
Only for top windows because for nested iframes they could get around
this without being noticed by reloading themselves which is not great.
Differential Revision: https://phabricator.services.mozilla.com/D98775
Before switching to using DocumentChannel to process multipart requests,
multipart documents loaded as a view-source load would be displayed their
plain-text data, as the multipart processing would be after the view-source
channel had wrapped the channel, and replaced the content type with
"application/x-view-source".
This change restores that behaviour, by preventing parent process multipart
processing for wrapped channels like `view-source` loads. This also allowed
removing the replaceRequest option on nsViewSourceChannel, as it was no longer
necessary, and required introducing a mechanism to get the inner http channel
for process switching.
The crash in Bug 1670530 was caused by a bad interaction between the view-source
replaceChannel logic, and the parent/content process switching logic, which
could lead to the load in the content process being initialized in a broken
state after a process switch, due to accidentally acting on a wrapped
view-source channel when an unwrapped one was expected. This patch also fixes
that issue, by removing the replaceRequest logic which caused it in the first
place.
Differential Revision: https://phabricator.services.mozilla.com/D98205
There are two issues in our current setup
1) Input events which are occurring in the same tab are going to be lost
because sync XHR. We have event handling suppression for synx XHR, so input
events are going to be discarded.
2) Input events that are happening in another tab (same process as the
synx XHR tab) are not going to be delayed. This is not correct since
sync XHR should block the Javascript execution.
This patches fixes the above cases for when both TaskController and e10s are
enabled by suspending the InputTaskManager during sync XHR, which
delays the input event handling and keeps the events around.
Differential Revision: https://phabricator.services.mozilla.com/D90780
### Story
While the exisiting top browsing context is replaced, SessionStorage relies on
itself been propagated by SessionStore. However, this has been disabled in
SessionHistory in the parent process.
Therefore, we need to propagate SessionStorage data by propagating
BackgroundSessionStorageManager.
### Notes
This patch assumes that the target top-level browsing context shouldn't have
been registered to BackgroundSessionStorageManager. If this can happen, we will
either need to merge SessionStorage data into it or find a proper (earlier)
place to update sManagers.
### Test Plan
Test: D97763
Try: https://treeherder.mozilla.org/jobs?repo=try&revision=2acc7b393fb80b640f4fbe3ade1da7dd440c380e&selectedTaskRun=KK6XhR-sQuqv5lcntVLc2w.0
Differential Revision: https://phabricator.services.mozilla.com/D98082
Before switching to using DocumentChannel to process multipart requests,
multipart documents loaded as a view-source load would be displayed their
plain-text data, as the multipart processing would be after the view-source
channel had wrapped the channel, and replaced the content type with
"application/x-view-source".
This change restores that behaviour, by preventing parent process multipart
processing for wrapped channels like `view-source` loads. This also allowed
removing the replaceRequest option on nsViewSourceChannel, as it was no longer
necessary, and required introducing a mechanism to get the inner http channel
for process switching.
The crash in Bug 1670530 was caused by a bad interaction between the view-source
replaceChannel logic, and the parent/content process switching logic, which
could lead to the load in the content process being initialized in a broken
state after a process switch, due to accidentally acting on a wrapped
view-source channel when an unwrapped one was expected. This patch also fixes
that issue, by removing the replaceRequest logic which caused it in the first
place.
Differential Revision: https://phabricator.services.mozilla.com/D98205
As far as I see the test is racy. It adds event listener to a window object, which reload() will replace.
So if the load event for non-transient about:blank gets chance to fire, then the test passes without the patch.
The main thing the patch does is to listen for the load event on the iframe element, since that object isn't
replaced.
The intermittent failure happens quite rarely and not locally, so the patch is based on code inspection.
Locally the test was run successfully 100 times both with opt and debug builds.
https://treeherder.mozilla.org/#/jobs?repo=try&revision=8b3c65c89c55cd16bf57cf0b78db9ee99ba23df2
Differential Revision: https://phabricator.services.mozilla.com/D98305
I think this allows us to remove TryUsePopupOpeningToken (which is a similar
concept to consuming user activation), and also the ad-hoc <iframe> timing
thing we have from bug 1514547, which should be covered by the user activation
timeout.
Depends on D97640
Differential Revision: https://phabricator.services.mozilla.com/D98020
This should prevent content process crashes when there are
cross-origin descendants with an override set.
There is a slight change in behaviour when an override is set after
a descendant context has previously set one. This shouldn't be a
problem since devtools only wants to expose touch simulation at the
tab level. Additionally this new behaviour is reasonable and would
allow devtools to implement the same semantics by doing the clearing
themselves (if needed).
Differential Revision: https://phabricator.services.mozilla.com/D97797
Before this change, a BrowsingContextGroup would fail to remove itself from a
ContentParent's mGroups table if the process was still launching when the BCG
was destroyed. This was because until the ContentParent had launched, it existed
only in the mHosts table, and not the mSubscribers table, but we only iterated
over the mSubscribers table.
This patch fixes that issue, by iterating over both tables when unsubscribing.
This will cause RemoveBrowsingContextGroup to be called twice on most
ContentParents, but that should not cause issues.
Differential Revision: https://phabricator.services.mozilla.com/D97788
This is only useful to potentially catch the case where we incorrectly
paint a non-visited link as visited. That's something covered by all the
visited reftests extensively, and can't cause the rest of the test to
race, so it seems removable.
Depends on D97774
Differential Revision: https://phabricator.services.mozilla.com/D97775
A new `BrowsingContext` field has been added to track the active
browser window for the `:-moz-window-inactive` pseudoclass. This
field takes the place of `nsPIDOMWindowOuter::mIsActive`.
With this change `:-moz-window-inactive` is now fission compatible.
Differential Revision: https://phabricator.services.mozilla.com/D86422
The guess in comment 3 is basically right, here's the relevant bits that
happen in that trace in order:
[content] nsFrameLoaderOwner::ChangeRemotenessCommon:
frame becomes remote for the content process.
[parent] WindowGlobalParent::SendMakeFrameLocal (mIsDocumentLoad=true)
[content] ContentChild::SendCloneDocumentTreeInto
[parent] ContentParent::RecvCloneDocumentTreeInto
[content] WindowGlobalChild::RecvMakeFrameLocal
So basically the source frame we're cloning is mid-switch-to-local:
local already from the parent process POV, but still remote for the
child.
I think ignoring the clone in this case is fine (which will make the
print iframe just about:blank).
I've decided it to handle it in ChangeRemoteness but I could also handle
it in RecvCloneDocumentTreeInto with a check like
if (cp->GetRemoteType() == GetRemoteType())
or such I think. Let me know if you'd prefer that.
Differential Revision: https://phabricator.services.mozilla.com/D97144
When re-enabling the test case blocked by bug 1670933 it became apparent that we were not allowing
session history entries to be marked with user interaction when the SH entry was created by navigation
through a sub-frame. The code that we had for this only covered updating SH entries after pushState etc.,
not adding new entries for document loads.
When SH lives in the child this is easier to manage in nsDocShell, but with Fission it probably makes sense
to move this code to the parent.
Differential Revision: https://phabricator.services.mozilla.com/D97421
This is more consistent than an assertion and it should be safe, considering that the field
should be unused on child entries anyway, so we might as well return the value from the root.
Differential Revision: https://phabricator.services.mozilla.com/D95300
Sam Foster
Olli Pettay
Csoregi Natalia
Andrew McCreight
Razvan Maries
Emilio Cobos Álvarez
Simon Giesecke
Brindusan Cristian
Daisuke Akatsuka
Nika Layzell
Sean Feng
Tom Tung
Narcis Beleuzu
Bogdan Tara
Steven MacLeod
Cristina Coroiu
Marco Bonardo
Butkovits Atila
Kartikaya Gupta
Anny Gakhokidze
Johann Hofmann
Henrik Skupin
Gerald Squelart