This test checks several replaced meta viewport tags, exercising the code in
MobileViewportManager that changes resolution to maintain the proportional
amount of content visible in the display area as the viewport size changes.
It also checks the shrink-to-fit behavior of pages with user-scalable=no.
Differential Revision: https://phabricator.services.mozilla.com/D72762
To reduce intermittents in RDM tests, setTouchAndMetaViewportSupport and
spawnViewportTask now await reflow before resolving. Additionally an awaited
reflow in setViewportSizeAndAwaitReflow was changed to use the standard
method.
Differential Revision: https://phabricator.services.mozilla.com/D72969
Display the buffer size as powers of 2, using binary-friendly units (e.g., 64MiB).
Presets have been adjusted to powers of 2.
Note that the profiler still uses this number as maximum per process, but this will change when bug 1632750 lands.
Differential Revision: https://phabricator.services.mozilla.com/D73213
The previous changeset removed all the usages of listRemoteFrames from
the frontend code. We can start removing this method from the actor codebase,
and keep backward compat code in the client.
Differential Revision: https://phabricator.services.mozilla.com/D65522
When navigating between process, we happen to destroy the AccessibleFront
in middle of this call to `Target.getFront("inspector")`.
Before calling updateDetails, we already check if AccessibleFront is already destroyed.
This code also checks after the call to getFront.
Differential Revision: https://phabricator.services.mozilla.com/D70842
Now that the BrowsingContextTarget are created by the watcher,
we should redirect existing code in the frontend which was using
`RootFront.getBrowsingContextDescriptor` in order to directly fetch the target from the watcher.
We don't really need descriptors for additional targets.
I think that descriptors are mostly useful for the top level target and for about:debugging, to describe a target without debugging it yet.
This patch is a bit complex because we can't fetch the "parent BrowsingContext ID" from actors/browsing-context.js:form().
browsingContext.parent and browsingContext.embedderWindowGlobal are both null from the content process.
I have not found any way/API to get the parent browsing context ID from the content process, i.e. the ID of browser.xhtml from a tab content process.
So, I end up with this helper method on Watcher actor to get the parent ID on-demand.
We could also inject the parent ID into the browsingContextTarget's form in WindowGlobalWatcher._createTarget,
but that sounds very hacky and hard to follow.
Note that this patch address the issue of duplicated targets.
WatcherFront.getBrowsingContextTarget ensures fetching the ParentProcessTarget for browser.xhtml
instead of recreating a duplicated FrameDescriptor and BrowsingContextTarget for this document, as we do in the existing codebase.
Differential Revision: https://phabricator.services.mozilla.com/D62465
* Introduce a new actor "Watcher", which might in the future allow listening to anything.
Here, it only implements listening for additional remote frame's WindowGlobal
and notify about the WindowGlobalTargetActor's.
* Also, very important part here is that it instantiates the BrowsingContextTargetActor much earlier. Before anything from the page is executed.
It requires to instantiate the actor directly from the content processes, whereas before, we were doing it from a frontend request, after a notification sent from the parent process to the frontend.
* Last but not least, make the TargetList use this new watcher actor in order to
notify the frontend about the dynamically added remote frames.
Differential Revision: https://phabricator.services.mozilla.com/D63317
The new `followWindowGlobalLifeCycle` argument and field makes the actor behaves like a WindowGlobalTargetActor and only care about the current global (and all its inner iframes, still).
But it ignores the previous/next document. We still uses the DebuggerProgressListener, but mostly for iframes.
will-navigate and navigate are irrelevant for this actor now.
The plan would be to eventually switch all codepaths to this WindowGlobalTargetActor and rename it.
For now, this would only be used for remoted iframes, only additional frame targets.
But not for top level document, nor top level target switching.
Differential Revision: https://phabricator.services.mozilla.com/D65521
When remote-debugging a device, it might happen that the device clock
is not exactly at the same time as the client clock. In such case, we
may end up in cases where the result of a command as an older timestamp,
which means we could have in the console output a result that was displayed
before the command message that triggered it.
In order to fix this, we add a `startTime` property on the evaluateJSAsync
response, that we can then check on the client. If the server time is
older than the client time, then we remove the existing command message
and add a new one, with the server timestamp.
We could have waited the result of the command before displaying the
command message (so we don't have to add a message, and then remove it
when the timestamps don't match), but the UI wouldn't feel snappy, and
even worse in case of long execution times (e.g. a top-level await fetch command).
Differential Revision: https://phabricator.services.mozilla.com/D72705
Now that we no longer have the various resolution shenanigans, we really
just want to ensure that child processes observe the resize of the
<browser> element, which can happen just fine if we ensure to flush
layout.
Differential Revision: https://phabricator.services.mozilla.com/D72552
Now that we no longer have the various resolution shenanigans, we really
just want to ensure that child processes observe the resize of the
<browser> element, which can happen just fine if we ensure to flush
layout.
Differential Revision: https://phabricator.services.mozilla.com/D72552
Depends on D71035
When F12 is disabled, if the user presses this key we show a notification hanging below the Firefox Hamburger menu.
This anchor was chosen because this is where the users can normally find the Web Developer menu.
Note that they could also open DevTools via another keyboard shortcut, even if it's not mentioned in the message.
Pressing on F12 again hides the message. The message will be displayed again if the user presses F12 again (ie, F12 is a toggle and the message is not just a one shot)
{F2136447}
Differential Revision: https://phabricator.services.mozilla.com/D71036
In this changeset, we add a preference that will simply disable F12 when it is set.
UI and tests are in followup patches
Differential Revision: https://phabricator.services.mozilla.com/D71035
When remote-debugging a device, it might happen that the device clock
is not exactly at the same time as the client clock. In such case, we
may end up in cases where the result of a command as an older timestamp,
which means we could have in the console output a result that was displayed
before the command message that triggered it.
In order to fix this, we add a `startTime` property on the evaluateJSAsync
response, that we can then check on the client. If the server time is
older than the client time, then we remove the existing command message
and add a new one, with the server timestamp.
We could have waited the result of the command before displaying the
command message (so we don't have to add a message, and then remove it
when the timestamps don't match), but the UI wouldn't feel snappy, and
even worse in case of long execution times (e.g. a top-level await fetch command).
Differential Revision: https://phabricator.services.mozilla.com/D72705
Depends on D61063
I broke this feature while working experimenting for this patch and it was not caught by any test.
Adding a test to avoid regressions.
Differential Revision: https://phabricator.services.mozilla.com/D68849
Depends on D71035
When F12 is disabled, if the user presses this key we show a notification hanging below the Firefox Hamburger menu.
This anchor was chosen because this is where the users can normally find the Web Developer menu.
Note that they could also open DevTools via another keyboard shortcut, even if it's not mentioned in the message.
Pressing on F12 again hides the message. The message will be displayed again if the user presses F12 again (ie, F12 is a toggle and the message is not just a one shot)
{F2136447}
Differential Revision: https://phabricator.services.mozilla.com/D71036
In this changeset, we add a preference that will simply disable F12 when it is set.
UI and tests are in followup patches
Differential Revision: https://phabricator.services.mozilla.com/D71035
This patch changes the lazy loading mechanism to explicitly create a "lazy" object
that can be used to load modules. It makes it so that TypeScript can understand what
is going on with the lazy loading. I couldn't find a solution to make the Object.define
mechanism work for the global object.
I briefly considered using the Object.define() method on the returned "lazy" object,
as this could be typed correctly, but I felt magically accessing properties was less
clear compared to calling a function that has the side effect of maybe loading a
module for the first time.
Differential Revision: https://phabricator.services.mozilla.com/D59208
This patch takes the approach from mossop on pre-defining ChromeUtils.import
paths, so that they don't need to be defined where they are used. Perhaps in
the future we could automate this more, but for now this will make the current
approach more ergonomic for consumers of the types.
Differential Revision: https://phabricator.services.mozilla.com/D59206
Julian Descottes
Brad Werth
Gerald Squelart
Alexandre Poirot
Razvan Maries
Nicolas Chevobbe
Daisuke Akatsuka
Emilio Cobos Álvarez
Dorel Luca
David Walsh
Yura Zenevich
Julien Wajsberg
Narcis Beleuzu
Greg Tatum