Without the other patches in this series, this test fails with both with and
without Fission enabled, for two different reasons.
With Fission disabled, the second reload request appears as empty, due to us
being unable to rewind the postData nsIInputStream. With Fission enabled, the
second reload request causes crashes due to the nsMIMEInputStream's invariant of
requiring a seekable stream is invalidated, causing the nsICloneableInputStream
implementation to misbehave.
Differential Revision: https://phabricator.services.mozilla.com/D101800
That doesn't go through BrowsingContext::InternalLoad. This matches the
behavior of clicking links and the behavior of other browsers.
Differential Revision: https://phabricator.services.mozilla.com/D103720
I'll simplify all the popup-blocking setup in a follow-up, but this is
the low-risk change.
Need to add a test for this of course. Kinda baffled we did not have
any.
Differential Revision: https://phabricator.services.mozilla.com/D103571
I'll simplify all the popup-blocking setup in a follow-up, but this is
the low-risk change.
Need to add a test for this of course. Kinda baffled we did not have
any.
Differential Revision: https://phabricator.services.mozilla.com/D103571
As a temporary fix to prevent crashes we are loosening the `CanSet`
restrictions for TouchEventsOverrideInternal. In the future this will
be fixed properly by changing DevTools to set this property from the
parent only, at which time tighter restrictions on setting
`TouchEventsOverrideInternal` may be added.
Differential Revision: https://phabricator.services.mozilla.com/D103080
Without the other patches in this series, this test fails with both with and
without Fission enabled, for two different reasons.
With Fission disabled, the second reload request appears as empty, due to us
being unable to rewind the postData nsIInputStream. With Fission enabled, the
second reload request causes crashes due to the nsMIMEInputStream's invariant of
requiring a seekable stream is invalidated, causing the nsICloneableInputStream
implementation to misbehave.
Differential Revision: https://phabricator.services.mozilla.com/D101800
The patch is based on code inspection. Crashes seem to happen when mHistory has been cleared,
and yet PendingAsyncHistoryNavigation::Run calls Go().
Differential Revision: https://phabricator.services.mozilla.com/D102874
Otherwise autoplay blocking until-in-foreground breaks with the other
patch in this bug, because it unblocks media playback once a browsing
context is active for the first time.
Differential Revision: https://phabricator.services.mozilla.com/D42329
Otherwise autoplay blocking until-in-foreground breaks with the other
patch in this bug, because it unblocks media playback once a browsing
context is active for the first time.
Differential Revision: https://phabricator.services.mozilla.com/D42329
Otherwise autoplay blocking until-in-foreground breaks with the other
patch in this bug, because it unblocks media playback once a browsing
context is active for the first time.
Differential Revision: https://phabricator.services.mozilla.com/D42329
Take a step towards replacing the encoding menu with a single menu item that
triggers the autodetection manually. However, don't remove anything for now.
* Add an autodetect item.
* Add telemetry for autodetect used in session.
* Add telemetry for non-autodetect used in session.
* Restore and revise telemetry for how the encoding that is being overridden
was discovered.
Differential Revision: https://phabricator.services.mozilla.com/D81132
Storing the charset on cache entries makes the code path uselessly different
when loading from cache relative to uncached loads. Also, for future
telemetry purposes, caching the charset obscures its original source.
Differential Revision: https://phabricator.services.mozilla.com/D101570
Syncing the container FeaturePolicy across BrowsingContext is actually
a bit more heavy-handed than necessary. We only ever need a container
FeaturePolicy when inheriting a FeaturePolicy in exactly the document
the container contains. Not every process that the tree the container
is a part of. So instead of storing a FeaturePolicy in a synced field,
we manually send it to the correct WindowGlobalChild (which
corresponds to a document) and retrieve it from there.
Differential Revision: https://phabricator.services.mozilla.com/D61479
In the case we click a link from inside the frame, we don't want to
check for activation from the parent window but ourselves.
It feels like using the sourceWindowContext for these checks is always
the right thing to do, but it's not always possible if we set the
location.href from an out-of-process parent. In this case, we fall back
to consuming user activation on the iframe itself. This is tested in
browbrowser_protocol_ask_dialog.js when run with fission enabled.
We could consider making the user activation stuff more
multiprocess-friendly, but it's not clear to me it's worth it for this
particular edge case.
Differential Revision: https://phabricator.services.mozilla.com/D100578
In the case we click a link from inside the frame, we don't want to
check for activation from the parent window but ourselves.
It feels like using the sourceWindowContext for these checks is always
the right thing to do, but it's not always possible if we set the
location.href from an out-of-process parent. In this case, we fall back
to consuming user activation on the iframe itself. This is tested in
browbrowser_protocol_ask_dialog.js when run with fission enabled.
We could consider making the user activation stuff more
multiprocess-friendly, but it's not clear to me it's worth it for this
particular edge case.
Differential Revision: https://phabricator.services.mozilla.com/D100578
I'm hoping this fixes (or at least helps with) this intermittent test failure
(an intermittent test-timeout).
Before this patch, the test did the following: it made a layout-impacting
restyle, and then it registered a reflow observer, and then it waited for the
previously-performed restyle to be flushed, which it then expects to cause a
reflow and trigger the reflow observer.
When the test times out and intermittently fails, it seems that the reflow
observer is successfully registered but never fires. I'm guessing that's
because the reflow is getting flushed eagerly for some reason, and happens
*before* the reflow observer is registered. We can avoid this problem by
holding off on the restyle until after the reflow observer has been registered;
that's the approach that this patch takes.
(Note that this reflow-observer API isn't web-exposed; it's an internal API that
we use to report reflows in our devtools.)
Differential Revision: https://phabricator.services.mozilla.com/D100517
Bug 1583109 introduced new function templates StringJoin and StringJoinAppend.
These are now used to replace several custom loops across the codebase that
implement string-joining algorithms to simplify the code.
Differential Revision: https://phabricator.services.mozilla.com/D98750
Bug 1583109 introduced new function templates StringJoin and StringJoinAppend.
These are now used to replace several custom loops across the codebase that
implement string-joining algorithms to simplify the code.
Differential Revision: https://phabricator.services.mozilla.com/D98750
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
Per spec, whenever a "beforeunload" event handler which would affect a
`location.reload()` call exists, it must be called before the `reload()` call
returns. If a handler requests to block the navigation and we choose to
display a confirmation prompt, that must also be displayed before the call
returns.
With session history in parent, though, that currently does not happen,
because `location.reload()` triggers an async IPC call to the parent process,
and only attempts the actual reload (and thus beforeunload dispatch and
prompting) once it returns, which is too late to affect the caller.
This patch changes the handling in this case to manually perform permit unload
checks before taking an async code path. This still leaves the opportunity for
session history handlers in the parent to cancel the load asynchronously, but
that doesn't violate any spec-defined behavior.
Differential Revision: https://phabricator.services.mozilla.com/D94354
aLink might be null in the parent process, and even though it's only
null when getting URIs via IPC (which should never hit this code path in
a correct execution), we don't trust the child process so this is safer.
Differential Revision: https://phabricator.services.mozilla.com/D99703
When a user clicks a form, the password manager popups a warning when the
form is not in a secure context. However, there is an exception when
a form is in an iframe. When both the url of the iframe and the top-level
are both local ip addresses, we consider it is safe.
This patch adds isLocalIP to WindowContext and WindowGlobalActor.webidl
so password manager can identify whether the top-level url is a local ip
address under fission.
Differential Revision: https://phabricator.services.mozilla.com/D99041
I think there could be still other issues with persist handling (or at least it could be simplified),
but this should be pretty much the minimal patch to fix the issue when
about:newtab url is changed to about:blank (without a redirect, but magical about: handling).
So we need to check persisted handling later than currently.
I'd prefer to land something like this first and then consider if there are better ways to handle
both about: url changes and proper redirects.
Depends on D93899
Differential Revision: https://phabricator.services.mozilla.com/D98871
And have it mirror in the parent process more automatically.
The docShellIsActive setter in the browser-custom-element side needs to
be there rather than in the usual DidSet() calls because the
AsyncTabSwitcher code relies on getting an exact amount of notifications
as response to that specific setter. Not pretty, but...
BrowserChild no longer sets IsActive() on the docshell itself for OOP
iframes. This fixes bug 1679521. PresShell activeness is used to
throttle rAF as well, which handles OOP iframes nicely as well.
Differential Revision: https://phabricator.services.mozilla.com/D96072
This moves parts of IPCMessageUtils.h to two new header files and adapts
the include directives as necessary. The new header files are:
- EnumSerializer.h, which defines the templates for enum serializers
- IPCMessageUtilsSpecializations.h, which defines template specializations
of ParamTraits with extra dependencies (building upon both IPCMessageUtils.h
and EnumSerializer.h)
This should minimize the dependencies pulled in by every consumer of
IPCMessageUtils.h
Differential Revision: https://phabricator.services.mozilla.com/D94459
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
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
This method only is async in order to allow callers to wait for a process switch
triggered by the call to `loadURI` to be finished before resolving. With
DocumentChannel, we should never trigger a process switch eagerly like this
again, so we don't need any of the async behaviour here anymore.
This part is largely mechanical changes to tests, removing the `await` calls on
`loadURI`, and a follow-up part will remove the actual async logic from
`BrowserTestUtils.loadURI`.
Differential Revision: https://phabricator.services.mozilla.com/D94641
This formed the backbone of the previous process switching codepath, and
shouldn't be necessary anymore thanks to DocumentChannel's new codepath.
This also removes the eager process switching logic from frontend's _loadURI, as
it would rarely be taken, unless an invalid URI was entered, already.
Differential Revision: https://phabricator.services.mozilla.com/D94639
The MOZ_MUST_USE macro is defined as clang's and gcc's nonstandard __attribute((warn_unused_result))__. Now that we compile as C++17 by default (bug 1560664), we can replace MOZ_MUST_USE with C++17's standard [[nodiscard]] attribute.
Differential Revision: https://phabricator.services.mozilla.com/D96802
Nika Layzell
Emilio Cobos Álvarez
Gijs Kruitbosch
Randell Jesup
Andreea Pavel
dluca
Kris Maglione
Mihai Alexandru Michis
Henri Sivonen
Steven MacLeod
Peter Van der Beken
Magnus Melin
Csoregi Natalia
Dimi Lee
Butkovits Atila
Olli Pettay
Cosmin Sabou
Yura Zenevich
smolnar
Geoff Lankow
Anny Gakhokidze
Noemi Erli
Masatoshi Kimura
Narcis Beleuzu
Micah Tigley
Andreas Farre
Alexis Beingessner
Razvan Maries
Sylvestre Ledru
Daniel Holbert
Andi-Bogdan Postelnicu
Jonathan Kew
Steve Fink
Yaron Tausky
Daisuke Akatsuka
Simon Giesecke
Sean Feng
Christoph Kerschbaumer
Sam Foster
Andrew McCreight
Brindusan Cristian
Tom Tung
Bogdan Tara
Cristina Coroiu
Marco Bonardo
Kartikaya Gupta
Johann Hofmann
Henrik Skupin
Gerald Squelart
Chris Peterson