We should always do this, otherwise stuff may not end up being visible which is
not acceptable for focus navigation.
Differential Revision: https://phabricator.services.mozilla.com/D70541
--HG--
extra : moz-landing-system : lando
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
When I first added this method last year, I added it in JS, handled from within
SessionStore.jsm, as that was the easiest place to do it. Now that
DocumentLoadListener exists, it makes more sense to handle this logic directly
from within that code.
Many parts of the process switch are still handled by frontend JS, such as
selecting remote types, and performing toplevel process switches.
Differential Revision: https://phabricator.services.mozilla.com/D68594
--HG--
extra : moz-landing-system : lando
This patch adds a `openWindowInfo` XPCOM attribute to the `nsIBrowser` interface
supported by the browser custom element. This attribute is then read by
`XULFrameElement`, and passed to `nsFrameLoader` to ensure the relevant flags
are used for newly opened windows.
This patch does not add support for passing openWindowInfo into mozbrowser
elements.
Differential Revision: https://phabricator.services.mozilla.com/D67052
--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
When I first added this method last year, I added it in JS, handled from within
SessionStore.jsm, as that was the easiest place to do it. Now that
DocumentLoadListener exists, it makes more sense to handle this logic directly
from within that code.
Many parts of the process switch are still handled by frontend JS, such as
selecting remote types, and performing toplevel process switches.
Differential Revision: https://phabricator.services.mozilla.com/D68594
--HG--
extra : moz-landing-system : lando
This patch adds a `openWindowInfo` XPCOM attribute to the `nsIBrowser` interface
supported by the browser custom element. This attribute is then read by
`XULFrameElement`, and passed to `nsFrameLoader` to ensure the relevant flags
are used for newly opened windows.
This patch does not add support for passing openWindowInfo into mozbrowser
elements.
Differential Revision: https://phabricator.services.mozilla.com/D67052
--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
Right now, we have a ContentBlockingAllowListPrincipal in the
WindowGlobalParent. So, the browse element can directly get this
principal from there. And we can stop sending the
ContentBlockingAllowListPrincipal from the content to parent when
OnLocationChange happens.
Differential Revision: https://phabricator.services.mozilla.com/D66212
--HG--
extra : moz-landing-system : lando
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
--HG--
rename : toolkit/modules/RemoteController.jsm => toolkit/actors/ControllersParent.jsm
extra : moz-landing-system : lando
After removing Fennec-specific media control and audio focus related code, now no one is using `mediaSuspend` attribute, so we can remove it as well.
Differential Revision: https://phabricator.services.mozilla.com/D65402
--HG--
extra : moz-landing-system : lando
This is like screenPixelsPerCSSPixel, but does not take into account the
RDM override of the device pixel ratio. It is needed to be able to correctly
compute the translation from window coordinates to screen coordinates
from inside the RDM pane.
Differential Revision: https://phabricator.services.mozilla.com/D63751
--HG--
extra : moz-landing-system : lando
Per discussing with @hiro, we should add new method to get viewport-fit
instead of adding parameter of `nsIDOMWindowUtils.getViewportInfo`.
Depends on D55609
Differential Revision: https://phabricator.services.mozilla.com/D57397
--HG--
extra : moz-landing-system : lando
`synthesizePlainDragAndDrop()` synthesizes drag events with `DataTransfer`
object which is set to `DragEvent.dataTransfer` of `dragstart` after starting
drag session explicitly. However, this causes
`EventStateManager::DoDefaltDragStart()` does not initialize `nsIDragService`
instance. Therefore, synthesized drag events cannot work with editor because
`DragEvent::GetMozSourceNode()` returns `nullptr` due to
`nsIDragSession::GetSourceNode()` returning `nullptr`.
On the other hand, synthesized drag events cannot use
`nsIDragService::InvodeDragSession()` normally because of hitting an assertion.
https://searchfox.org/mozilla-central/rev/690e903ef689a4eca335b96bd903580394864a1c/widget/nsBaseDragService.cpp#230-233
This patch does:
- mark drag events caused by synthesized mouse events as "synthesized for tests"
- make `synthesizePlainDragAndDrop()` stop using
`nsIDragService.startDragSession()`
- make `nsBaseDragService` initialize and start session even for synthesized
`dragstart` event
- make `synthesizePlainDragAndDrop()` stop synthesizing drag events with
`DataTransfer` object since it's normal behavior and it'll be initialized
with `nsIDragService::GetDataTransfer()`
- make `nsBaseDragService` store `effectAllowed` for the session only when
it's synthesized session because it's required at initializing synthesized
default `dropEffect` value of `dragenter`, `dragover`, `dragexit` and `drop`
events' `dataTransfer`
- make all tests which use `nsIDragService.startDragSession()` use new
API, `nsIDragService.startDragSessionForTests()` to initialize session's
`effectAllowed` value
- make `EventStateManager::PostHandleEvent()` set drag end point of the test
session to `eDrop` event's screen point
- make `synthesizePlainDragAndDrop()` set drag end point of the session if
it does not synthesize `drop` event because following `endDragSession()`
use it at dispatching `dragend` event on the source element
Additionally, this adds `dumpFunc` new param to `synthesizePlainDragAndDrop()`
because it's really useful to investigate the reason why requesting DnD isn't
performed as expected.
Differential Revision: https://phabricator.services.mozilla.com/D57425
--HG--
extra : moz-landing-system : lando
On GTK changing gtk-enable-animation in a process doesn't affect in different
processes for some reasons. So we take the same approach as what we did for
OSX[1] that is when SetPrefersReducedMotionOverrideForTest is called we set the
given value as a cache in the parent process and send a notification to system
as if the value changed thus the notification kicks PBroser.ThemeChanged to
update the cache in the content process, thus we can use the cache value on
querying the corresponding value in the content process.
[1] https://hg.mozilla.org/mozilla-central/rev/67a5acf7363d
Differential Revision: https://phabricator.services.mozilla.com/D57260
--HG--
extra : moz-landing-system : lando
On GTK changing gtk-enable-animation in a process doesn't affect in different
processes for some reasons. So we take the same approach as what we did for
OSX[1] that is when SetPrefersReducedMotionOverrideForTest is called we set the
given value as a cache in the parent process and send a notification to system
as if the value changed thus the notification kicks PBroser.ThemeChanged to
update the cache in the content process, thus we can use the cache value on
querying the corresponding value in the content process.
[1] https://hg.mozilla.org/mozilla-central/rev/67a5acf7363d
Differential Revision: https://phabricator.services.mozilla.com/D57260
--HG--
extra : moz-landing-system : lando
The idea of this patch is to try to not use oberver mechanism as possible. To
achieve that, it introduces deleteByOriginAttributes() to cleaners. Different
from other methods, it would only be executed if it's implemented from a
cleaner.
It doesn't remove oberver mechanism entirely since some cleaners are still using
that for other deleteByXXX() functions. So, it only applies removing stuff to
PushService, QuotaManagerService, ServiceWorkerManager, nsPermissionManager,
nsApplicationCacheService, and nsCookieService.
Since the original issue is related to QuotaManagerService, it adds xpcshell
test under the dom/quota/test/unit/ to ensure the behavior won't be changed
accidentally in the future.
Differential Revision: https://phabricator.services.mozilla.com/D33758
--HG--
extra : moz-landing-system : lando
Emilio Cobos Álvarez
Csoregi Natalia
pbz
Christoph Kerschbaumer
Bogdan Tara
Oana Pop Rus
Nika Layzell
Cosmin Sabou
Dão Gottwald
Henri Sivonen
Tim Huang
Simon Giesecke
Kartikaya Gupta
Neil Deakin
Alastor Wu
Matt Woodrow
Dorel Luca
Andrew McCreight
Ciure Andrei
Botond Ballo
Makoto Kato
Dimi Lee
Thomas Nguyen
Masayuki Nakano
Hiroyuki Ikezoe
Tom Tung
Johann Hofmann
Brian Hackett