This patch introduces a new tab modal system prompt type. It can be opened via the nsIPromptService
with a destination BrowsingContext. These tab system prompts overlap slightly with the upper
chrome UI to differentiate them from content prompts (previously called tab prompts).
- Extended nsIPromptService and nsIPrompt to accept 3 types of modal prompts:
- Window prompts
- Tab (system) prompts
- Content prompts (the old tab prompts)
- Removed prompt code from Prompter.jsm, always call PromptParent window actor instead
- Added PromptChild window actor to forward pagehide events to parent actor
- Created additional prompt methods in nsIPromptService to prompt by browsingContext and modalType
- Backwards compatibility is maintained, consumers can still open content prompts calling nsIPrompt with a content window
Differential Revision: https://phabricator.services.mozilla.com/D66446
Currently, with Fission enabled we are not able to create a proper LoadInfo
object when doing a subdocument load because we do not have access to a loading
context if the load is happening inside of an OOP frame. To solve this problem,
we can create LoadInfo object from scratch in the parent process where we have
all of the required information.
Differential Revision: https://phabricator.services.mozilla.com/D68893
Currently, with Fission enabled we are not able to create a proper LoadInfo
object when doing a subdocument load because we do not have access to a loading
context if the load is happening inside of an OOP frame. To solve this problem,
we can create LoadInfo object from scratch in the parent process where we have
all of the required information.
Differential Revision: https://phabricator.services.mozilla.com/D68893
WindowFeature provides the tokenization and access to the map.
This changes the following behavior:
* "*" value is removed, given it's unused.
* Default width and default height handling is removed,
given there's no callsites
* Some chrome-priv feature handling becomes stricter:
* All substring match is removed and directly checks the item in the map
Also, fixed noopener=0 and noreferrer=0 options to be handled properly.
Differential Revision: https://phabricator.services.mozilla.com/D67725
WindowFeature provides the tokenization and access to the map.
This changes the following behavior:
* "*" value is removed, given it's unused.
* Default width and default height handling is removed,
given there's no callsites
* Some chrome-priv feature handling becomes stricter:
* All substring match is removed and directly checks the item in the map
Also, fixed noopener=0 and noreferrer=0 options to be handled properly.
Differential Revision: https://phabricator.services.mozilla.com/D67725
This patch introduces a new tab modal system prompt type. It can be opened via the nsIPromptService
with a destination BrowsingContext. These tab system prompts overlap slightly with the upper
chrome UI to differentiate them from content prompts (previously called tab prompts).
- Extended nsIPromptService and nsIPrompt to accept 3 types of modal prompts:
- Window prompts
- Tab (system) prompts
- Content prompts (the old tab prompts)
- Removed prompt code from Prompter.jsm, always call PromptParent window actor instead
- Added PromptChild window actor to forward pagehide events to parent actor
- Created additional prompt methods in nsIPromptService to prompt by browsingContext and modalType
- Backwards compatibility is maintained, consumers can still open content prompts calling nsIPrompt with a content window
Differential Revision: https://phabricator.services.mozilla.com/D66446
These properties used to be passed to newly created content windows in many
different ways, but are now unified under nsOpenWindowInfo. This patch cleans up
the remaining properties.
Differential Revision: https://phabricator.services.mozilla.com/D67056
TabGroup never really made any difference in which thread something go
dispatched to. This was the intended use, but development of TabGroups
with abstract main threads never made it that far. The good thing is
that thish makes it safe to also remove to the SystemGroup and instead
switch all SystemGroup dispatches to dispatches to main thread.
Timers for setTimeout and workers were the sole users of wrapped and
throttled event targets, that those throttled queues have been moved
to the BrowsingContextGroup and are now accessed explicitly.
The SchedulerEventTarget has been removed, since there are no longer a
separate event target for every TaskCategory. Instead a
LabellingEventTarget has been added to DocGroup to handle the case
where an event is dispatched do DocGroup or when an AbstractThread is
created using a DocGroup. This means that we'll actually label more
events correctly with the DocGroup that they belong to.
DocGroups have also been moved to BrowsingContextGroup.
Depends on D67636
Differential Revision: https://phabricator.services.mozilla.com/D65936
These properties used to be passed to newly created content windows in many
different ways, but are now unified under nsOpenWindowInfo. This patch cleans up
the remaining properties.
Differential Revision: https://phabricator.services.mozilla.com/D67056
We propagate the HasStoragePermission flag from the loadInfo to the
WindowContext in the patch. We add a flag HasStoragePermission in the
document and this flag will get updated when the
Document::StartDocumentLoad() happens. And then, we would sync this to
the WindowContext in the final stage of the
nsGlobalWindowOuter::SetNewDocument() where the WindowContext is ready.
Differential Revision: https://phabricator.services.mozilla.com/D67471
We nuke xray waivers when we navigate outer windows out of process,
because it doesn't make much sense to have a waiver in that case.
This patch makes the behavior for navigating to local outer windows
consistent, by also nuking remote window proxies. Hopefully that
won't break anything.
This is Nightly-only for now, because it might break addons.
Differential Revision: https://phabricator.services.mozilla.com/D66495
When searching for the controller for a command in nsWindowRoot::GetControllerForCommand, look for a focused browsing context instead and get the controller through the Controllers actor associated with that browsing context. When a command update occurs in a window in the child process, send the list of commands to the parent process along with the browsing context for that window. The parent will pass this information to the controllers actor. As long as we can get the right currently focused browsing context descendant, we can get the correct command state and invoke commands through the right actor.
Differential Revision: https://phabricator.services.mozilla.com/D66222
We sync the CookieJarSettings to the WindowContext in
Document::StartDocumentLoad(). This is incorrect because the inner
window hasn't been set to the document in
Document::StartDocumentLoad(). So, the CookieJarSettings doesn't be
synced properly to the WindowContext.
This patch fixes this issue by changing the place where we do the sync. It
changes it to do the sync at the end of
nsGlobalWindowOuter::SetNewDocument() where the inner window and the
window context are both ready for the document.
Differential Revision: https://phabricator.services.mozilla.com/D66207
Given that we are going to add ContentBlockingAllowList in
CookieSettings, so CookieSettings will be responsible for more stuff than the
cookie behavior and cookie permission. We should use a proper name to
reflect the purpose of it. The name 'CookieSettings' is misleading that
this is only for cookie related stuff. So, we decide to rename
'CookieSettins' to 'CookieJarSettings' which serves better meaning here.
Differential Revision: https://phabricator.services.mozilla.com/D63935
The method is exposed only if the consumer has the same principal as the PDF
would have if it were not getting the PDF viewer treatment.
The method just calls the print() method in the PDF viewer window.
It's enough to expose this on nsOuterWindowProxy, not RemoteOuterWindowProxy,
because PDF documents end up in the process they would have been in based on
their pre-PDF-viewer principal, since we do process determination in the parent
process but only run the pdfjs stream converter in the content process, once we
have decided which one to use.
Differential Revision: https://phabricator.services.mozilla.com/D63711
