2006-02-07 23:46:39 +03:00
|
|
|
/* -*- Mode: C++; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2 -*-
|
2001-02-04 03:32:43 +03:00
|
|
|
*
|
2012-05-21 15:12:37 +04:00
|
|
|
* This Source Code Form is subject to the terms of the Mozilla Public
|
|
|
|
* License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
|
|
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
|
2001-02-04 03:32:43 +03:00
|
|
|
|
2001-04-17 00:35:46 +04:00
|
|
|
/* Private "control" methods on the Window Watcher. These are annoying
|
|
|
|
bookkeeping methods, not part of the public (embedding) interface.
|
|
|
|
*/
|
|
|
|
|
2001-02-04 03:32:43 +03:00
|
|
|
#include "nsISupports.idl"
|
|
|
|
|
2018-06-30 02:29:50 +03:00
|
|
|
%{ C++
|
2018-10-30 03:13:29 +03:00
|
|
|
class nsDocShellLoadState;
|
2018-06-30 02:29:50 +03:00
|
|
|
%}
|
|
|
|
|
Bug 1561015: Part 2 - Return BrowsingContext from openWindow2. r=bzbarsky
There are some unfortunate aspects of openWindow() and openWindow2() that make
this difficult. Namely, they sometimes return top-level chrome windows, and
sometimes a single content window from the top-level chrome window that they
open, depending on how they're called.
There really isn't any reason to return a BrowsingContext rather than a chrome
window in the former case, but there also really isn't a way to make the API
polymorphic in a way that would allow handling the two cases differently. So
at some point, the two cases should ideally be split into separate APIs rather
than separate special cases of a single API.
In the mean time, I've left openWindow() returning local mozIDOMWindowProxy
objects, since it isn't used by the DOM window.open() or openDialog() APIs,
and only updated openWindow2(). As a follow-up, we should remove both
openWindow() and openWindow2(), and replace them with openChromeWindow() and
openContentWindow() (or similar) methods which make it immediately clear what
type of window is being returned.
Differential Revision: https://phabricator.services.mozilla.com/D35689
--HG--
extra : moz-landing-system : lando
2019-08-02 23:48:40 +03:00
|
|
|
webidl BrowsingContext;
|
2016-01-30 20:05:36 +03:00
|
|
|
interface mozIDOMWindowProxy;
|
2001-02-04 03:32:43 +03:00
|
|
|
interface nsISimpleEnumerator;
|
2001-04-17 00:35:46 +04:00
|
|
|
interface nsIWebBrowserChrome;
|
2005-03-03 20:26:34 +03:00
|
|
|
interface nsIDocShellTreeItem;
|
2006-06-13 07:07:47 +04:00
|
|
|
interface nsIArray;
|
2019-04-09 23:59:37 +03:00
|
|
|
interface nsIRemoteTab;
|
2020-04-08 00:39:32 +03:00
|
|
|
interface nsIOpenWindowInfo;
|
2018-10-30 03:13:29 +03:00
|
|
|
native nsDocShellLoadStatePtr(nsDocShellLoadState*);
|
2001-02-04 03:32:43 +03:00
|
|
|
|
2016-01-30 20:05:36 +03:00
|
|
|
[uuid(d162f9c4-19d5-4723-931f-f1e51bfa9f68)]
|
2001-02-04 03:32:43 +03:00
|
|
|
interface nsPIWindowWatcher : nsISupports
|
|
|
|
{
|
|
|
|
/** A window has been created. Add it to our list.
|
|
|
|
@param aWindow the window to add
|
2001-04-17 00:35:46 +04:00
|
|
|
@param aChrome the corresponding chrome window. The DOM window
|
|
|
|
and chrome will be mapped together, and the corresponding
|
|
|
|
chrome can be retrieved using the (not private)
|
|
|
|
method getChromeForWindow. If null, any extant mapping
|
|
|
|
will be cleared.
|
2001-02-04 03:32:43 +03:00
|
|
|
*/
|
2016-01-30 20:05:36 +03:00
|
|
|
void addWindow(in mozIDOMWindowProxy aWindow,
|
|
|
|
in nsIWebBrowserChrome aChrome);
|
2001-02-04 03:32:43 +03:00
|
|
|
|
|
|
|
/** A window has been closed. Remove it from our list.
|
|
|
|
@param aWindow the window to remove
|
|
|
|
*/
|
2016-01-30 20:05:36 +03:00
|
|
|
void removeWindow(in mozIDOMWindowProxy aWindow);
|
2001-02-04 03:32:43 +03:00
|
|
|
|
Bug 1636728 - Centralize printing entry points in nsGlobalWindowOuter, and move cloning out of nsPrintJob. r=jwatt,geckoview-reviewers,smaug,agi
This centralizes our print and preview setup in nsGlobalWindowOuter so
that we never re-clone a clone, and so that we reuse the window.open()
codepath to create the browsing context to clone into.
For window.print, for both old print dialog / silent printing and new
print preview UI, we now create a hidden browser (as in with visibility:
collapse, which takes no space but still gets a layout box).
* In the modern UI case, this browser is swapped with the actual print
preview clone, and the UI takes care of removing the browser.
* In the print dialog / silent printing case, the printing code calls
window.close() from nsDocumentViewer::OnDonePrinting().
* We don't need to care about the old print preview UI for this case
because it can't be open from window.print().
We need to fall back to an actual window when there's no
nsIBrowserDOMWindow around for WPT print tests and the like, which don't
have one. That seems fine, we could special-case this code path more if
needed but it doesn't seem worth it.
Differential Revision: https://phabricator.services.mozilla.com/D87063
2020-08-25 20:45:12 +03:00
|
|
|
cenum PrintKind : 8 {
|
|
|
|
PRINT_NONE,
|
2020-10-09 17:59:46 +03:00
|
|
|
PRINT_INTERNAL,
|
|
|
|
PRINT_WINDOW_DOT_PRINT,
|
Bug 1636728 - Centralize printing entry points in nsGlobalWindowOuter, and move cloning out of nsPrintJob. r=jwatt,geckoview-reviewers,smaug,agi
This centralizes our print and preview setup in nsGlobalWindowOuter so
that we never re-clone a clone, and so that we reuse the window.open()
codepath to create the browsing context to clone into.
For window.print, for both old print dialog / silent printing and new
print preview UI, we now create a hidden browser (as in with visibility:
collapse, which takes no space but still gets a layout box).
* In the modern UI case, this browser is swapped with the actual print
preview clone, and the UI takes care of removing the browser.
* In the print dialog / silent printing case, the printing code calls
window.close() from nsDocumentViewer::OnDonePrinting().
* We don't need to care about the old print preview UI for this case
because it can't be open from window.print().
We need to fall back to an actual window when there's no
nsIBrowserDOMWindow around for WPT print tests and the like, which don't
have one. That seems fine, we could special-case this code path more if
needed but it doesn't seem worth it.
Differential Revision: https://phabricator.services.mozilla.com/D87063
2020-08-25 20:45:12 +03:00
|
|
|
};
|
|
|
|
|
2012-08-14 18:58:00 +04:00
|
|
|
/** Like the public interface's open(), but can handle openDialog-style
|
|
|
|
arguments and calls which shouldn't result in us navigating the window.
|
|
|
|
|
2005-09-10 08:16:59 +04:00
|
|
|
@param aParent parent window, if any. Null if no parent. If it is
|
|
|
|
impossible to get to an nsIWebBrowserChrome from aParent, this
|
|
|
|
method will effectively act as if aParent were null.
|
2001-03-23 06:14:55 +03:00
|
|
|
@param aURL url to which to open the new window. Must already be
|
|
|
|
escaped, if applicable. can be null.
|
2006-02-07 23:46:39 +03:00
|
|
|
@param aName window name from JS window.open. can be null. If a window
|
|
|
|
with this name already exists, the openWindow call may just load
|
|
|
|
aUrl in it (if aUrl is not null) and return it.
|
2001-03-23 06:14:55 +03:00
|
|
|
@param aFeatures window features from JS window.open. can be null.
|
2012-08-14 18:58:00 +04:00
|
|
|
@param aCalledFromScript true if we were called from script.
|
2019-11-05 07:52:53 +03:00
|
|
|
@param aDialog use dialog defaults (see nsGlobalWindowOuter::OpenInternal)
|
2012-08-14 18:58:00 +04:00
|
|
|
@param aNavigate true if we should navigate the new window to the
|
|
|
|
specified URL.
|
2006-06-13 07:07:47 +04:00
|
|
|
@param aArgs Window argument
|
2016-10-20 23:52:38 +03:00
|
|
|
@param aIsPopupSpam true if the window is a popup spam window; used for
|
|
|
|
popup blocker internals.
|
2016-10-20 23:52:38 +03:00
|
|
|
@param aForceNoOpener If true, force noopener behavior. This means not
|
|
|
|
looking for existing windows with the given name,
|
|
|
|
not setting an opener on the newly opened window,
|
|
|
|
and returning null from this method.
|
2018-10-30 03:13:29 +03:00
|
|
|
@param aLoadState if aNavigate is true, this allows the caller to pass in
|
|
|
|
an nsIDocShellLoadState to use for the navigation.
|
2016-10-20 23:52:38 +03:00
|
|
|
Callers can pass in null if they want the windowwatcher
|
|
|
|
to just construct a loadinfo itself. If aNavigate is
|
|
|
|
false, this argument is ignored.
|
2016-10-20 23:52:38 +03:00
|
|
|
|
2001-02-17 05:45:42 +03:00
|
|
|
@return the new window
|
2006-02-07 23:46:39 +03:00
|
|
|
|
|
|
|
@note This method may examine the JS context stack for purposes of
|
|
|
|
determining the security context to use for the search for a given
|
|
|
|
window named aName.
|
|
|
|
@note This method should try to set the default charset for the new
|
|
|
|
window to the default charset of the document in the calling window
|
|
|
|
(which is determined based on the JS stack and the value of
|
|
|
|
aParent). This is not guaranteed, however.
|
2001-02-17 05:45:42 +03:00
|
|
|
*/
|
Bug 1636728 - Centralize printing entry points in nsGlobalWindowOuter, and move cloning out of nsPrintJob. r=jwatt,geckoview-reviewers,smaug,agi
This centralizes our print and preview setup in nsGlobalWindowOuter so
that we never re-clone a clone, and so that we reuse the window.open()
codepath to create the browsing context to clone into.
For window.print, for both old print dialog / silent printing and new
print preview UI, we now create a hidden browser (as in with visibility:
collapse, which takes no space but still gets a layout box).
* In the modern UI case, this browser is swapped with the actual print
preview clone, and the UI takes care of removing the browser.
* In the print dialog / silent printing case, the printing code calls
window.close() from nsDocumentViewer::OnDonePrinting().
* We don't need to care about the old print preview UI for this case
because it can't be open from window.print().
We need to fall back to an actual window when there's no
nsIBrowserDOMWindow around for WPT print tests and the like, which don't
have one. That seems fine, we could special-case this code path more if
needed but it doesn't seem worth it.
Differential Revision: https://phabricator.services.mozilla.com/D87063
2020-08-25 20:45:12 +03:00
|
|
|
[noscript]
|
2020-07-28 00:36:24 +03:00
|
|
|
BrowsingContext openWindow2(in mozIDOMWindowProxy aParent, in ACString aUrl,
|
|
|
|
in ACString aName, in ACString aFeatures,
|
Bug 1561015: Part 2 - Return BrowsingContext from openWindow2. r=bzbarsky
There are some unfortunate aspects of openWindow() and openWindow2() that make
this difficult. Namely, they sometimes return top-level chrome windows, and
sometimes a single content window from the top-level chrome window that they
open, depending on how they're called.
There really isn't any reason to return a BrowsingContext rather than a chrome
window in the former case, but there also really isn't a way to make the API
polymorphic in a way that would allow handling the two cases differently. So
at some point, the two cases should ideally be split into separate APIs rather
than separate special cases of a single API.
In the mean time, I've left openWindow() returning local mozIDOMWindowProxy
objects, since it isn't used by the DOM window.open() or openDialog() APIs,
and only updated openWindow2(). As a follow-up, we should remove both
openWindow() and openWindow2(), and replace them with openChromeWindow() and
openContentWindow() (or similar) methods which make it immediately clear what
type of window is being returned.
Differential Revision: https://phabricator.services.mozilla.com/D35689
--HG--
extra : moz-landing-system : lando
2019-08-02 23:48:40 +03:00
|
|
|
in boolean aCalledFromScript,
|
|
|
|
in boolean aDialog,
|
|
|
|
in boolean aNavigate,
|
|
|
|
in nsISupports aArgs,
|
|
|
|
in boolean aIsPopupSpam,
|
|
|
|
in boolean aForceNoOpener,
|
|
|
|
in boolean aForceNoReferrer,
|
Bug 1636728 - Centralize printing entry points in nsGlobalWindowOuter, and move cloning out of nsPrintJob. r=jwatt,geckoview-reviewers,smaug,agi
This centralizes our print and preview setup in nsGlobalWindowOuter so
that we never re-clone a clone, and so that we reuse the window.open()
codepath to create the browsing context to clone into.
For window.print, for both old print dialog / silent printing and new
print preview UI, we now create a hidden browser (as in with visibility:
collapse, which takes no space but still gets a layout box).
* In the modern UI case, this browser is swapped with the actual print
preview clone, and the UI takes care of removing the browser.
* In the print dialog / silent printing case, the printing code calls
window.close() from nsDocumentViewer::OnDonePrinting().
* We don't need to care about the old print preview UI for this case
because it can't be open from window.print().
We need to fall back to an actual window when there's no
nsIBrowserDOMWindow around for WPT print tests and the like, which don't
have one. That seems fine, we could special-case this code path more if
needed but it doesn't seem worth it.
Differential Revision: https://phabricator.services.mozilla.com/D87063
2020-08-25 20:45:12 +03:00
|
|
|
in nsPIWindowWatcher_PrintKind aPrintKind,
|
Bug 1561015: Part 2 - Return BrowsingContext from openWindow2. r=bzbarsky
There are some unfortunate aspects of openWindow() and openWindow2() that make
this difficult. Namely, they sometimes return top-level chrome windows, and
sometimes a single content window from the top-level chrome window that they
open, depending on how they're called.
There really isn't any reason to return a BrowsingContext rather than a chrome
window in the former case, but there also really isn't a way to make the API
polymorphic in a way that would allow handling the two cases differently. So
at some point, the two cases should ideally be split into separate APIs rather
than separate special cases of a single API.
In the mean time, I've left openWindow() returning local mozIDOMWindowProxy
objects, since it isn't used by the DOM window.open() or openDialog() APIs,
and only updated openWindow2(). As a follow-up, we should remove both
openWindow() and openWindow2(), and replace them with openChromeWindow() and
openContentWindow() (or similar) methods which make it immediately clear what
type of window is being returned.
Differential Revision: https://phabricator.services.mozilla.com/D35689
--HG--
extra : moz-landing-system : lando
2019-08-02 23:48:40 +03:00
|
|
|
in nsDocShellLoadStatePtr aLoadState);
|
2001-02-17 05:45:42 +03:00
|
|
|
|
2016-07-05 19:00:07 +03:00
|
|
|
/**
|
|
|
|
* Opens a new window so that the window that aOpeningTab belongs to
|
|
|
|
* is set as the parent window. The newly opened window will also
|
|
|
|
* inherit load context information from aOpeningTab.
|
|
|
|
*
|
|
|
|
* @param aOpeningTab
|
2019-04-09 23:59:37 +03:00
|
|
|
* The nsIRemoteTab that is requesting the new window be opened.
|
2016-07-05 19:00:07 +03:00
|
|
|
* @param aFeatures
|
|
|
|
* Window features if called with window.open or similar.
|
|
|
|
* @param aCalledFromJS
|
|
|
|
* True if called via window.open or similar.
|
|
|
|
* @param aOpenerFullZoom
|
|
|
|
* The current zoom multiplier for the opener tab. This is then
|
|
|
|
* applied to the newly opened window.
|
2020-04-08 00:39:32 +03:00
|
|
|
* @param aOpenWindowInfo
|
|
|
|
* Information used to create the initial content browser in the new
|
|
|
|
* window.
|
2021-10-29 05:32:59 +03:00
|
|
|
*
|
|
|
|
* @return the nsIRemoteTab of the initial browser for the newly opened
|
|
|
|
* window.
|
2016-07-05 19:00:07 +03:00
|
|
|
*/
|
2021-10-29 05:32:59 +03:00
|
|
|
nsIRemoteTab openWindowWithRemoteTab(in nsIRemoteTab aOpeningTab,
|
|
|
|
in ACString aFeatures,
|
|
|
|
in boolean aCalledFromJS,
|
|
|
|
in float aOpenerFullZoom,
|
|
|
|
in nsIOpenWindowInfo aOpenWindowInfo);
|
2001-02-04 03:32:43 +03:00
|
|
|
};
|
|
|
|
|