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
--HG--
extra : moz-landing-system : lando
This method is no longer necessary, as frontend will always make the correct
decisions for the remoteness of the intial content browser by reading
openWindowInfo.
Differential Revision: https://phabricator.services.mozilla.com/D67058
--HG--
extra : moz-landing-system : lando
This patch builds on top of part 7.1 by creating this object within
nsWindowWatcher and ContentParent to carry the relevant information through
provider interfaces when creating new content windows. The nsOpenWindowInfo
object is not created for new chrome windows.
This patch does not propagate these flags all of the way through to the
nsFrameLoader. That change is performed in later parts to keep each part
smaller.
Differential Revision: https://phabricator.services.mozilla.com/D67051
--HG--
extra : moz-landing-system : lando
This type replaces the individual properties, like nextRemoteTabId and
presetOpenerWindow, which were passed around by frontend code for window opening
requests performed by Gecko. This new type is intentionally native-only to make
it easier to pass more information down to newly created windows in the future.
Differential Revision: https://phabricator.services.mozilla.com/D67050
--HG--
extra : moz-landing-system : lando
This is necessary as, by this point, the BrowsingContext has already been
attached, and can no longer have its nsILoadContext flags updated.
Differential Revision: https://phabricator.services.mozilla.com/D67049
--HG--
extra : moz-landing-system : lando
Many of these setters are redundant, and duplicate work done elsewhere. As it is
no longer correct to set nsILoadContext attributes at these times, they're being
replaced with assertions.
Differential Revision: https://phabricator.services.mozilla.com/D67047
--HG--
extra : moz-landing-system : lando
This is OK, as all chrome BrowsingContext instances are always in the same
BrowsingContextGroup, so we don't need to have the initial opener avaliable when
creating the BrowsingContext to determine its BrowsingContextGroup.
This is used in part 7.2 to avoid propagating the opener window around when
creating chrome windows.
Differential Revision: https://phabricator.services.mozilla.com/D67044
--HG--
extra : moz-landing-system : lando
This could cause issues, as we could incorrectly override the decision made by
nsWindowWatcher, and then override the decision again after the method returns.
This could cause the initial content browser to be configured incorrectly.
Differential Revision: https://phabricator.services.mozilla.com/D67043
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
This method is no longer necessary, as frontend will always make the correct
decisions for the remoteness of the intial content browser by reading
openWindowInfo.
Differential Revision: https://phabricator.services.mozilla.com/D67058
--HG--
extra : moz-landing-system : lando
This patch builds on top of part 7.1 by creating this object within
nsWindowWatcher and ContentParent to carry the relevant information through
provider interfaces when creating new content windows. The nsOpenWindowInfo
object is not created for new chrome windows.
This patch does not propagate these flags all of the way through to the
nsFrameLoader. That change is performed in later parts to keep each part
smaller.
Differential Revision: https://phabricator.services.mozilla.com/D67051
--HG--
extra : moz-landing-system : lando
This type replaces the individual properties, like nextRemoteTabId and
presetOpenerWindow, which were passed around by frontend code for window opening
requests performed by Gecko. This new type is intentionally native-only to make
it easier to pass more information down to newly created windows in the future.
Differential Revision: https://phabricator.services.mozilla.com/D67050
--HG--
extra : moz-landing-system : lando
This is necessary as, by this point, the BrowsingContext has already been
attached, and can no longer have its nsILoadContext flags updated.
Differential Revision: https://phabricator.services.mozilla.com/D67049
--HG--
extra : moz-landing-system : lando
Many of these setters are redundant, and duplicate work done elsewhere. As it is
no longer correct to set nsILoadContext attributes at these times, they're being
replaced with assertions.
Differential Revision: https://phabricator.services.mozilla.com/D67047
--HG--
extra : moz-landing-system : lando
This is OK, as all chrome BrowsingContext instances are always in the same
BrowsingContextGroup, so we don't need to have the initial opener avaliable when
creating the BrowsingContext to determine its BrowsingContextGroup.
This is used in part 7.2 to avoid propagating the opener window around when
creating chrome windows.
Differential Revision: https://phabricator.services.mozilla.com/D67044
--HG--
extra : moz-landing-system : lando
This could cause issues, as we could incorrectly override the decision made by
nsWindowWatcher, and then override the decision again after the method returns.
This could cause the initial content browser to be configured incorrectly.
Differential Revision: https://phabricator.services.mozilla.com/D67043
--HG--
extra : moz-landing-system : lando
Make the features parameter of window.open just a condition for whether to open
a popup or a new tab.
Also remove dom.disable_window_open_feature.* prefs.
Differential Revision: https://phabricator.services.mozilla.com/D65926
--HG--
extra : moz-landing-system : lando
Make the features parameter of window.open just a condition for whether to open
a popup or a new tab.
Also remove dom.disable_window_open_feature.* prefs.
Differential Revision: https://phabricator.services.mozilla.com/D65926
--HG--
extra : moz-landing-system : lando
Csoregi Natalia
pbz
Kris Maglione
Bogdan Tara
Oana Pop Rus
Nika Layzell
Andreas Farre
Cosmin Sabou
Narcis Beleuzu
Tooru Fujisawa
Noemi Erli
Kashav Madan
Simon Giesecke
Simon Van Accoleyen
Mark Banner
shindli
Alphan Chen
Henri Sivonen
Coroiu Cristina