Use the newly added session storage data getter to access the session
storage in the parent and store it in session store without a round
trip to content processes.
Depends on D111433
Differential Revision: https://phabricator.services.mozilla.com/D111434
For inserting text from OS in special cases, e.g., when inserting 2 or more characters
per keydown or inserting text without key press, we use a set of composition events on
macOS, but the other browsers don't use composition events. Instead, they expose only
`beforeinput` event and `input` event. We should follow their behavior for web-compat
because `beforeinput` events for IME composition are never cancelable, but the
`beforeinput` events for the cases are cancelable of the other browsers.
Differential Revision: https://phabricator.services.mozilla.com/D114826
For inserting text from OS in special cases, e.g., when inserting 2 or more characters
per keydown or inserting text without key press, we use a set of composition events on
macOS, but the other browsers don't use composition events. Instead, they expose only
`beforeinput` event and `input` event. We should follow their behavior for web-compat
because `beforeinput` events for IME composition are never cancelable, but the
`beforeinput` events for the cases are cancelable of the other browsers.
Differential Revision: https://phabricator.services.mozilla.com/D114826
With Fission, there can be multiple BrowserParents in a single tab, so
this patch moves the tracking of active tabs onto the top BrowsingContext
in a tab. If the priority of a top BC is changed, then the activity
of all of the BPs of the BCs in the tree are all adjusted. The flag
that tracks this state gets carried forward to the new BC in the case
of a cross-group navigation by the changes in ReplacedBy().
The other change here covers the case where we do a process-switching
navigation on an iframe. If we create a new BrowserParent with an active
top BC, then the BP gets marked as active in the priority manager. Doing
this tracking on the BP instead of the BC (both here in and in the part
that landed previously in BrowserParent::Deactivated()) means that we
don't need to track down every place that a BC switches processes.
I left the tracking of activity in ParticularProcessPriorityManager
centered around BrowserParents, instead of changing it to BCs, to
minimize the changes required. There are some tricky interactions there
with wakelocks that I didn't want to have to figure out.
browser_ProcessPriorityManager.js was set up to track a mapping of
browsers to priorities, but for the purposes of testing Fission support
I changed it to track a mapping of child IDs to priorities.
In the test, I also removed an assignment (this.window = null) that
didn't seem to be doing anything.
Differential Revision: https://phabricator.services.mozilla.com/D112213
With Fission, there can be multiple BrowserParents in a single tab, so
this patch moves the tracking of active tabs onto the top BrowsingContext
in a tab. If the priority of a top BC is changed, then the activity
of all of the BPs of the BCs in the tree are all adjusted. The flag
that tracks this state gets carried forward to the new BC in the case
of a cross-group navigation by the changes in ReplacedBy().
The other change here covers the case where we do a process-switching
navigation on an iframe. If we create a new BrowserParent with an active
top BC, then the BP gets marked as active in the priority manager. Doing
this tracking on the BP instead of the BC (both here in and in the part
that landed previously in BrowserParent::Deactivated()) means that we
don't need to track down every place that a BC switches processes.
I left the tracking of activity in ParticularProcessPriorityManager
centered around BrowserParents, instead of changing it to BCs, to
minimize the changes required. There are some tricky interactions there
with wakelocks that I didn't want to have to figure out.
browser_ProcessPriorityManager.js was set up to track a mapping of
browsers to priorities, but for the purposes of testing Fission support
I changed it to track a mapping of child IDs to priorities.
In the test, I also removed an assignment (this.window = null) that
didn't seem to be doing anything.
Differential Revision: https://phabricator.services.mozilla.com/D112213
This should be mostly straight-forward, since we have code for this
anyways for image-set() and srcset.
The only thing is that we were using floats for resolution, but since
EXIF allows you to scale each axis separately, we now need to pass an
image::Resolution instead.
The main outstanding issue is the spec comment mentioned in the previous
patch, about what happens if you have srcset/image-set and the image
density specified together. For now I've implemented what the
image-set() spec says, but this is subject to change before shipping of
course.
Differential Revision: https://phabricator.services.mozilla.com/D113265
This should be mostly straight-forward, since we have code for this
anyways for image-set() and srcset.
The only thing is that we were using floats for resolution, but since
EXIF allows you to scale each axis separately, we now need to pass an
image::Resolution instead.
The main outstanding issue is the spec comment mentioned in the previous
patch, about what happens if you have srcset/image-set and the image
density specified together. For now I've implemented what the
image-set() spec says, but this is subject to change before shipping of
course.
Differential Revision: https://phabricator.services.mozilla.com/D113265
On Wayland, it is not possible to warp the pointer.
To use the appropriate protocols, new IPC messages were added for supporting
a platform's native pointer locking mechanism.
Differential Revision: https://phabricator.services.mozilla.com/D102114
This required more refactoring so it seemed sensible to split it out. GTK
doesn't seem to provide an API for scaled cursors so we get pixelated cursors
instead.
Differential Revision: https://phabricator.services.mozilla.com/D112676
This removes some sketchy non-caching of cursors on windows while at it,
now that plugins are gone, but otherwise shouldn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D112475
The priority manager tracks which browser parents are active in each process,
so it needs to be told when a browser parent is no longer active. This
is currently implemented by observing ipc:browser-destroyed, which happens
in BrowserHost::DestroyComplete().
However, with Fission, not all BrowserParents are held by BrowserHosts. I
don't think this is an issue right now, but if the priority manager is going
to properly prioritize processes due to the presence of active non-top-level
frames, then it needs to also deprioritize them when they go away.
This patch deals with this situation by directly telling the priority
manager that the browser parent is becoming inactive via the existing
ActivityChanged method, in the BrowserParent::Deactivated() method,
which is called when a browser parent is being destroyed or entering
the BF cache. I think it makes sense in both cases that we no longer
want to prioritize the process that the page is in.
This does mean that we are telling the priority manager about more
ContentParents which is potentially more expensive, but the old code
also ended up doing a hashtable remove in every single
ParticularProcessPriorityManager, whereas the new code only does it
for one, so hopefully it is a net win overall.
(The reason for this is that in ParticularProcessPriorityManager's
OnBrowserParentDestroyed() method the browserHost->GetContentParent()
check will always return null because the browser host nulls out
mRoot immediately before it does ipc:browser-destroyed, so the hash
table remove is never skipped.)
This patch also removes the last thing that ParticularProcessPriorityManager
was observing, so it no longer needs to be an nsIObserver.
Differential Revision: https://phabricator.services.mozilla.com/D111654
As of the next patch, it won't be used just for indicating the
activity of an entire tab, so let's rename it.
Also alphabetize the order of some forward declarations.
Differential Revision: https://phabricator.services.mozilla.com/D111701
This patch contains a large number of changes around the process switching
mechanism in order to avoid issues which are caused by a mismatched
understanding of the state of the process switch between processes in the
presence of nested event loops.
This includes:
1. The "InFlightProcessId" value is no longer recorded. All remaining uses
were removed in part 1, and the new mechanism tracks this information in
a better way.
2. The current BrowserParent instance is now tracked on
CanonicalBrowsingContext, meaning that logic which needs to work with this
information can now access it without depending on the current
WindowGlobalParent instance.
3. When doing a process switch, the previous host process for the
BrowsingContext is tracked until the process switch is completed, allowing
for future attempts to switch into that process to be delayed until the
previous unload event has finished running.
4. The process switch logic was refactored to simplify some of the
error-handling logic, and share more code between different cases.
Differential Revision: https://phabricator.services.mozilla.com/D110002
This patch contains a large number of changes around the process switching
mechanism in order to avoid issues which are caused by a mismatched
understanding of the state of the process switch between processes in the
presence of nested event loops.
This includes:
1. The "InFlightProcessId" value is no longer recorded. All remaining uses
were removed in part 1, and the new mechanism tracks this information in
a better way.
2. The current BrowserParent instance is now tracked on
CanonicalBrowsingContext, meaning that logic which needs to work with this
information can now access it without depending on the current
WindowGlobalParent instance.
3. When doing a process switch, the previous host process for the
BrowsingContext is tracked until the process switch is completed, allowing
for future attempts to switch into that process to be delayed until the
previous unload event has finished running.
4. The process switch logic was refactored to simplify some of the
error-handling logic, and share more code between different cases.
Differential Revision: https://phabricator.services.mozilla.com/D110002
Instead of collecting data from the entire tree of documents, we
collect data per document. The collected data is sent to the
corresponding parent window context and is applied incrementally to
the tab state cache.
Differential Revision: https://phabricator.services.mozilla.com/D107814
Instead of collecting data from the entire tree of documents, we
collect data per document. The collected data is sent to the
corresponding parent window context and is applied incrementally to
the tab state cache.
Differential Revision: https://phabricator.services.mozilla.com/D107814
Creating an event with type NSEventTypeSmartMagnify does not work with either NSEvent mouseEventWithType or NSEvent otherEventWithType (they both hit an assert in the appkit code). So the best we can do is call the same function.
Differential Revision: https://phabricator.services.mozilla.com/D107792
This URI is intended to reflect the currentURI field on the content nsIDocShell,
and is the value used for getters like `window.location.href`. For most
documents, this generally matches the Document URI on WindowGlobalParent, it
does not match in specific cases such as error pages or when performing a
session restore.
The field is kept up-to-date by listening to `OnLocationChange` notifications
from the content process, and is ignored when the BrowsingContext is loaded in
the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D105559
Previously, we would need to suspend progress events from the previous
BrowserParent, as otherwise we would receive STATE_STOP progress notifications
from the previous browser when it is destroyed, which would throw off frontend
code. With the new checks added by part 1, we will now catch these cases by
detecting that the current window global has changed, and we can get rid of this
explicit override.
Differential Revision: https://phabricator.services.mozilla.com/D105557
This change allows associating individual web progress events with which frame
they originate from, rather than only recording the `isToplevel` information as
we were before, which is necessary in order to use the OnLocationChange events
from content to track the current URI on CanonicalBrowsingContext.
Due to events in ContentChild being filtered through nsBrowserStatusFilter, some
of the callbacks will never be passed nsIRequest or nsIWebProgress pointers, and
this patch also simplifies them by removing information which is not necessary
from the IPC message.
Finally, this patch adds a number of checks to the relevant Recv callbacks in
the parent process which help ensure that it does not accept web progress events
from a content process which is no longer hosting the target BrowsingContext.
This may allow for us to stop manually suspending web progress events on process
switches, as these checks will handle this automatically based on the existing
BrowsingContext and WindowContext objects.
Differential Revision: https://phabricator.services.mozilla.com/D105556
