`_onToolbarArrowKeypress` is only concerned with moving focus between tabs in the toolbar when the right/left arrow keys are pressed. This patch ensures the listener is only added to the container of the tab elements (.devtools-tabbar).
Depends on D70279
Differential Revision: https://phabricator.services.mozilla.com/D72227
The DebugTargetInfo component doesn't receive new target information when navigation occurs. This is because the ToolboxController doesn't seem to be aware of these changes. To trigger an update, we can force new props to be passed to DebugTargetInfo by setting the target's debug info on its local state.
Differential Revision: https://phabricator.services.mozilla.com/D70280
`_onToolbarArrowKeypress` is only concerned with moving focus between tabs in the toolbar when the right/left arrow keys are pressed. This patch ensures the listener is only added to the container of the tab elements (.devtools-tabbar).
Depends on D70279
Differential Revision: https://phabricator.services.mozilla.com/D72227
The DebugTargetInfo component doesn't receive new target information when navigation occurs. This is because the ToolboxController doesn't seem to be aware of these changes. To trigger an update, we can force new props to be passed to DebugTargetInfo by setting the target's debug info on its local state.
Differential Revision: https://phabricator.services.mozilla.com/D70280
This removes processing of HTTP Public Key Pinning headers, remotely modifying
pinning information, and using cached pinning information, all of which was
already disabled in bug 1412438. Static pins that ship with the browser are
still enforced.
Differential Revision: https://phabricator.services.mozilla.com/D73352
Included in this patch
- Reduced the size of the raw header toggles from 16px to 12px
- The raw header toggles when the "Raw" label is clicked
- The label has changed for "Raw headers" to "Raw" as recommende by the UX designs
- Changed the Title text color of the headers accordion to make it lighter
- Disabled the input boxes when property values are selected
- Changed the color of the property values
Todo (in a different patch)
- Show learn more and copy icons on hover
- No warning icons
Differential Revision: https://phabricator.services.mozilla.com/D73230
Raw Cr.ERROR don't get stack information, same as throwing JS literals instead
of `new Error()`s.
This was done automatically with a new eslint rule that will be introduced in
the next commit. One instance of a raw Cr.ERROR was not replaced since it is
used in a test that specifically checks the preservation of raw Cr values in
XPCJS. The rule will be disabled for that instance.
Differential Revision: https://phabricator.services.mozilla.com/D28073
When the completed word has character after it,
we don't display the completion text (the grey
text that indicates what will be added to the
input if you press enter), and we keep the autocomplete
popup open, even if there's only one item in it.
But in the code where we're mitigating races on
autocompletion, we were having a check on the completionText
existence, which would not cover the cases where the
popup is shown but not the completion text.
By changing the condition in the if, the issue is fixed.
A test case is added to ensure this works as expected
and that we don't regress.
Differential Revision: https://phabricator.services.mozilla.com/D73612
We no longer need to fire fake mouse events after replacing `sendTouchEvent` with `sendNativeTouchPoint` in D69885.
Depends on D69885
Differential Revision: https://phabricator.services.mozilla.com/D72905
This allow us to not have to declare both Ctrl and Cmd + F extra keys
for CodeMirror; which fixes the OSX Ctrl+F default behaviour (move
cursor one char forward).
Differential Revision: https://phabricator.services.mozilla.com/D73598
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
The changes made here are meant to make the screenshot code in DevTools
closer to how the Firefox Screenshots addon works.
1. It cuts off large images to 10000x10000
2. It reduces drp to 1 for fullpage images
When those things happen, a warning is logged in the content console so
the user is aware that they did happen.
Finally, because there are still cases when taking a screenshot could fail,
an error is logged in the content console when this happens.
Differential Revision: https://phabricator.services.mozilla.com/D62945
In this patch we add a new resource type for page errors.
We don't do anything specific for CSS Warnings yet, as they're going
to be handled as part of Bug 1625910.
A test is added (following devtools/shared/webconsole/test/chrome/test_page_errors.html
as an example).
A couple function that were used for the console-messages test
are moved into head.js as they're also used in the error-message test.
Differential Revision: https://phabricator.services.mozilla.com/D71955
This patch trades a bit of CSS code duplication for the sake of making styles more independent and less prone to break.
- Remove usage of `devtools-button` in the toolbox's toolbar.
- Create a ad-hoc `devtools-tabbar-button` style specifically for the toolbox icon buttons.
Differential Revision: https://phabricator.services.mozilla.com/D72488
In this patch we actually have separate `Worker` and `Registration` components. All workers belonging to the same registration appear together under it.
{F2134654}
Note: I left the `Debug` button shown for every worker because sometimes we do have a target even though the worker might be waiting. I'm not sure when/how this happens, but I was able to debug it as well.
{F2134655}
BTW I found a quick –and more reliable? I seems I don't need to reload- way of testing this. **STR**:
- Start a local HTTP server at `mozilla-central/devtools/client/application/test/browser/resources/service-workers`
- Open `localhost:8080/simple.html` (or whatever the port) and open devtools there
- Open `localhost:8080/debug.html` (or whatever the port) and open devtools there
You should be able to see both workers under the same registration scope.
Differential Revision: https://phabricator.services.mozilla.com/D72173
As a result of the first part review and some testing, there were some issues re: repeating things among workers that actually belonged to the registration (the ID's for React keys, `Unregister` button, `Last updated` time…).
Initially I wanted to do the "grouping" of all the workers belonging to the same registration, but I think this is less confusing to use and test.
This patch initiates that work by renaming our `WorkerList` and `WorkerListEmpty` components to `Registration*`.
Differential Revision: https://phabricator.services.mozilla.com/D72172
In this patch we add a new resource type for page errors.
We don't do anything specific for CSS Warnings yet, as they're going
to be handled as part of Bug 1625910.
A test is added (following devtools/shared/webconsole/test/chrome/test_page_errors.html
as an example).
A couple function that were used for the console-messages test
are moved into head.js as they're also used in the error-message test.
Differential Revision: https://phabricator.services.mozilla.com/D71955
Micah Tigley
Daisuke Akatsuka
Razvan Maries
Ian Moody
Cosmin Sabou
Dana Keeler
Gijs Kruitbosch
Yura Zenevich
AaryanDewan
Belén Albeza
Nicolas Chevobbe
Julian Descottes
Hubert Boma Manilla
Julien Wajsberg
Farooq AR
Greg Tatum
Ria agnes Jose
Harshil Agrawal
Sonia Singla
Ciure Andrei
Brad Werth
Gerald Squelart
Alexandre Poirot
Emilio Cobos Álvarez
Dorel Luca
David Walsh
Narcis Beleuzu
Nika Layzell
Christoph Kerschbaumer
Mats Palmgren
Jean-Yves Avenard
Andreea Pavel
Patrick Brosset
Florens Verschelde
Andreas Farre
Logan Smyth
Stefan Hindli
Jason Laster
GranjonAntoine
Bogdan Tara