Revert to using CSS pseudo-elements for the +/- diff markers in the Changes panel so they don't get copied over as plain text to the clipboard.
Differential Revision: https://phabricator.services.mozilla.com/D58768
--HG--
extra : moz-landing-system : lando
When a page navigation happens, we update the state of the toolbox toolbar buttons
as some of them need to disable themselves then (rulers and measurement tool).
In bug 1500142 the logic to do this was changed to retrieve the right inspector front
instead of always the top-level one, stored at toolbox level.
This is good. However a tiny mistake made its way into the code.
Instead of calling getCachedFront("inspector") the code called
getCachedFront("inspectorFront")
This made it return null, and therefore prevented the rest of the button update logic
to run.
Differential Revision: https://phabricator.services.mozilla.com/D57997
--HG--
extra : moz-landing-system : lando
Styled the Outline pane filter to be consistent with the Event Breakpoint filter
Differential Revision: https://phabricator.services.mozilla.com/D50977
--HG--
extra : moz-landing-system : lando
The function was moved during Bug 1582870 and
we lost the return statement somehow.
Differential Revision: https://phabricator.services.mozilla.com/D58798
--HG--
extra : moz-landing-system : lando
Since the name can be an undefined grip, there
could be case where the name would be an object
and not a React element, making the rendering fail.
This patch fixes that and adds a test to ensure
this does not regress.
Differential Revision: https://phabricator.services.mozilla.com/D58747
--HG--
extra : moz-landing-system : lando
The 3 `test_objectgrips-fn-apply` tests and 3 `test_objectgrips-property-value` tests used somewhat complicated callbacks returning `promise` . I thought they were not easy to read, and I might fail to understand its subtleness. I wondered why the tests were written in that way?
Differential Revision: https://phabricator.services.mozilla.com/D57752
--HG--
extra : moz-landing-system : lando
For test browser_net_prefs-reload.js, I am not sure about this change firstValue/currentValue seems to be different types numbers, strings, objects.
toString is maybe not the best way to compare those values.
Differential Revision: https://phabricator.services.mozilla.com/D58313
--HG--
extra : moz-landing-system : lando
For test browser_net_prefs-reload.js, I am not sure about this change firstValue/currentValue seems to be different types numbers, strings, objects.
toString is maybe not the best way to compare those values.
Differential Revision: https://phabricator.services.mozilla.com/D58313
--HG--
extra : moz-landing-system : lando
Move the content of bug1503420.html to
test_frame_reconstruction_for_column_span.html because we don't need to
flip the pref and load the test in an iframe.
The modification to devtools's properties-db.js is generated via
`./mach devtools-css-db`.
Differential Revision: https://phabricator.services.mozilla.com/D58402
--HG--
extra : moz-landing-system : lando
We then convert that to `#aarrggbb` in GeckoView for convenient use
with `android.graphics.Color`.
Differential Revision: https://phabricator.services.mozilla.com/D57689
--HG--
extra : moz-landing-system : lando
Setting the values for the pref explicitly will make the test run in the same way regardless of the channel
(this pref is true on Nightly only at the moment)
Differential Revision: https://phabricator.services.mozilla.com/D57966
--HG--
extra : moz-landing-system : lando
We were breaking twice in the browser toolbox because we were attaching to
all the content process targets as well as all frame targets.
But as frames (i.e. web pages) are running within the content processes,
we were having two thread actor attached to the same thread.
This is a stopgap solution for the browser toolbox and we would need
to do something better for the content toolboxes.
Differential Revision: https://phabricator.services.mozilla.com/D57505
--HG--
extra : moz-landing-system : lando
The ReflowTracker was based on the assumption that there was only ever going to
be one target to be observed.
With Fission, this is no longer true.
Turning the ReflowTracker into something that is multi-target aware seemed more
complex than really worth it. After all, all it was doing is getting a ReflowFront
and listening for events on it.
The only 3 things that needed it are the grid inspector, flex inspector and box
model widget. They all needed it for the same reason: updating the data displayed
in the UI when the size/geometry/box-model regions of the selected node changed.
So, it seems simpler to let the inspector instantiate the right ReflowFront when
it needs it (upon a new node selection).
There's only one node selected at any given time in the inspector, so it's simple
to just listen for reflow in that node's target, and dispatch events to the grid,
flex and box-model tools so they can update themselves.
Note that once a new node is selected, we do the `getFront("Reflow")` again
since that node can be in a different target than the previous one. If it is,
however, in the same target, then `getFront` will return the same instance which
is nice.
Differential Revision: https://phabricator.services.mozilla.com/D55987
--HG--
extra : moz-landing-system : lando
This is exactly the kind of test that makes no sense once we have finished
the rework of RDM (to be embedded into the browser UI). Indeed, once done,
there won't be a nested iframe in RDM through which we need to make sure
all messages that lead to the tab status/title/icon (and many other things)
are forwarded.
So, because this test currently fails with fission, let's just disable it
for now when in fission mode, and then once the RDM project is done, let's
delete it entirely. No use spending time making it work now if we're going
to remove it later.
Differential Revision: https://phabricator.services.mozilla.com/D57758
--HG--
extra : moz-landing-system : lando
If the test only fails today with fission with the old RDM, then it makes no
sense to fix that now. Better wait for the new RDM to be enabled as it will
probably change how this test runs.
Differential Revision: https://phabricator.services.mozilla.com/D57798
--HG--
extra : moz-landing-system : lando
Variables are retrieved from CodeMirror state and sent to the
webconsole actor, where the filtering is done.
Differential Revision: https://phabricator.services.mozilla.com/D57427
--HG--
extra : moz-landing-system : lando
This ensures the selected item of the autocomplete
popup is updated, so if the user accepts the completion
it will retrieve the right text.
Differential Revision: https://phabricator.services.mozilla.com/D57342
--HG--
extra : moz-landing-system : lando
The failure indicates a pending request to the highlighter
actor. This patch moves the mouse at the top left corner of
the console to avoid hovering any dom elements that might
trigger the highlighter.
Differential Revision: https://phabricator.services.mozilla.com/D57345
--HG--
extra : moz-landing-system : lando
This patch places the mouse cursor at the top left corner so
it does not inadvertently triggers an highlighter.
Differential Revision: https://phabricator.services.mozilla.com/D57343
--HG--
extra : moz-landing-system : lando
Show the size only in Raw Data, because showing it on all tabs is redundant and on Raw makes most sense.
Differential Revision: https://phabricator.services.mozilla.com/D52607
--HG--
extra : moz-landing-system : lando
Fission changes made it so the `PageStyle` is referenced contextually from the `InspectorFront` of the `NodeFront` wherever needed. Most references in the code no longer use the static reference to `PageStyle` from the Inspector client (which only points to the top-level document anyway).
This patch removes that reference from the Inspector client and updates any leftover bits to use the contextual `PageStyle` from the abandoned /new Rules view and some tests.
The Shapes Highlighter tests will be refactored separately in [Bug 1603066](https://bugzilla.mozilla.org/show_bug.cgi?id=1603066). This patch just corrects the references without attempting to cleanup the tests themselves.
Differential Revision: https://phabricator.services.mozilla.com/D56714
--HG--
extra : moz-landing-system : lando
We don't want to run stream conversion in the parent (since a lot of them require access to the document), so this instead adds a way to find out what their output type will be.
Differential Revision: https://phabricator.services.mozilla.com/D56134
--HG--
extra : moz-landing-system : lando
We are being inconsistent here and sometimes calling `.connect` with a
Debugger.Object that points at a global instead of the global itself.
Passing the Debugger.Object fails since it isn't a global.
Differential Revision: https://phabricator.services.mozilla.com/D57270
--HG--
extra : moz-landing-system : lando
We don't want to run stream conversion in the parent (since a lot of them require access to the document), so this instead adds a way to find out what their output type will be.
Differential Revision: https://phabricator.services.mozilla.com/D56134
--HG--
extra : moz-landing-system : lando
This will help VSCode users (jump to definition will work with absolute paths)
and opens the door to implementing typescript JS docs.
I tested it with absolute and regular paths, with `require` and `from`.
Differential Revision: https://phabricator.services.mozilla.com/D56863
--HG--
extra : moz-landing-system : lando
This will be helpful when consumers don't want to
keep the target around.
A test is added to ensure this work as expected (and
was failing if the returned function does not call
EventEmitter.off).
Differential Revision: https://phabricator.services.mozilla.com/D56685
--HG--
extra : moz-landing-system : lando
ContentTask tasks have a different lifetime than SpecialPowers tasks, with the
former being tied to the lifetime of a message manager and the latter tied to
the lifetime of a window global. That means that existing ContentTask callers
which expect to be able to register load listeners before the creation of a
window global, or which expect to persist after a page has navigated, won't
work as SpecialPowers tasks.
Since those sorts of tasks are not really resilient in the face of Fission,
they should really be written to work differently, but this patch mostly just
reverts them to using ContentTask for the time being.
Differential Revision: https://phabricator.services.mozilla.com/D53744
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
CheckMayLoadAndReport takes a window ID. This allows us to report
errors from it to the web console as needed. Most consumers know statically
whether they want reporting or not, so there's no reason to force the ones that
don't to provide window ids.
Differential Revision: https://phabricator.services.mozilla.com/D56388
--HG--
extra : moz-landing-system : lando
This patch does several related things:
1) Updates the test helper functions in ui.js to make them sensible
for both the old and new RDM UI.
2) Updates the test helper function addRDMTask to return the correct
"browser" values for both RDM UIs. Old RDM UI tests that want to
spawn a content task should now use ui.getViewportBrowser() for that,
and only use the browser value for getting/setting of zoom and any
other methods that take browsers as arguments.
3) Updates the test helper function promiseRDM to make it wait on
the correct event.
4) Updates a non-zoom test that uses addRDMTask to use the new
browser value correctly.
5) Updates a zoom test to use the addRDMTask function, and therefore
run the test using the new RDM UI. This test exercises the issue
that is the focus of this bug.
Differential Revision: https://phabricator.services.mozilla.com/D56510
--HG--
extra : moz-landing-system : lando
The firing of the "ZoomComplete" event is no longer necessary, now
that ZoomParent fires a "PostFullZoomChange" event, which serves a
similar purpose. The next part of the patch listens for that event.
Differential Revision: https://phabricator.services.mozilla.com/D56509
--HG--
extra : moz-landing-system : lando
Because the new RDM UI does not retain the width and height of the
device, this patch extracts those values from the prefs which are
updated in the viewports reducer. There probably should be a more
resilient way to maintain those values.
Differential Revision: https://phabricator.services.mozilla.com/D54379
--HG--
extra : moz-landing-system : lando
Not everything that blocks requests sets a reason other than BLOCKING_REASON_NONE.
Differential Revision: https://phabricator.services.mozilla.com/D57072
--HG--
extra : moz-landing-system : lando
This revision introduces a check for whether or not grid-item properties have an affect on an “absolutely-positioned” grid element. It’s important to note this grid element is not necessarily a grid item, it just needs to be contained within a grid container that generates its containing block. The general algorithm for this is to first check whether or not the element is either `position: fixed` or `position: absolute` then find an ancestor grid element that generates its containing block.
To help DevTools identify such an element, InspectorUtils provides an API called `containingBlockOf` that returns the absolutely-positioned element’s containing block. If the element’s containing block is the viewport, then this method returns null. For now, `containingBlockOf` is designed for absolute/fixed positioned elements. So it’s important to be aware that trying to use it for other purposes might return unexpected results.
This revision also adds/updates tests that check whether or not grid-item properties are active on a grid element.
Differential Revision: https://phabricator.services.mozilla.com/D55400
--HG--
extra : moz-landing-system : lando
Since `parent_intercept` requires to be set from the beginning, either we disable the test when it's not the case, or we force the pref to be flipped for this test… I chose the former, but happy to do the latter if it's preferable.
Differential Revision: https://phabricator.services.mozilla.com/D56762
--HG--
extra : moz-landing-system : lando
Depends on D56330
Renaming the "tab" getter to "localTab" will make it easier to refactor later.
Differential Revision: https://phabricator.services.mozilla.com/D56331
--HG--
extra : moz-landing-system : lando
Depends on D56327. Not reason to make target-mixin more complex for this workaround which already has access to the tab object.
Differential Revision: https://phabricator.services.mozilla.com/D56330
--HG--
extra : moz-landing-system : lando
It is not clear why tab unload should be listened to on the client, and only destroy the target front.
Tentatively removing to simplify the local tab target.
Differential Revision: https://phabricator.services.mozilla.com/D56327
--HG--
extra : moz-landing-system : lando
This will be helpful when consumers don't want to
keep the target around.
A test is added to ensure this work as expected (and
was failing if the returned function does not call
EventEmitter.off).
Differential Revision: https://phabricator.services.mozilla.com/D56685
--HG--
extra : moz-landing-system : lando
All the rejections were called with 2 arguments, when reject only
cares about the first one.
This patch makes all the reject called with the actual DOMException,
and adds console.error before all those rejections.
Differential Revision: https://phabricator.services.mozilla.com/D56859
--HG--
extra : moz-landing-system : lando
Some tests are failing on Linux ccov when adding
item to the webconsole history. I suspect it could
be because some expression have emojis, but I'm
not sure.
Catching the rejection will at least not make the
test fail.
Differential Revision: https://phabricator.services.mozilla.com/D56744
--HG--
extra : moz-landing-system : lando
Request a ChangesFront for each target as soon as is becomes available.
The on-demand approach in D54725 is abandoned because it introduces a client-server round trip on _every_ CSS mutation operation due to the need to ensure the ChangesActor is instantiated. By awaiting `changesFront.setup()` on every mutation, needless slowdown is introduced after the actor becomes available. Furthermore, the approach in D54725 spreads the knowledge about the ChangesFront in too many places in the codebase, something that will only get worse over time as the ChangesActor gains capabilities to track CSS changes from other sources or supports tracking DOM changes.
Differential Revision: https://phabricator.services.mozilla.com/D55945
--HG--
extra : moz-landing-system : lando
CheckMayLoadAndReport takes a window ID. This allows us to report
errors from it to the web console as needed. Most consumers know statically
whether they want reporting or not, so there's no reason to force the ones that
don't to provide window ids.
Differential Revision: https://phabricator.services.mozilla.com/D56388
--HG--
extra : moz-landing-system : lando
The UA input field gets caught off when the browser viewport is too small. This is because the RDM toolbar has an explicit height of 30px set on it, so it can't accomodate the second row created for the UA input.
Differential Revision: https://phabricator.services.mozilla.com/D56783
--HG--
extra : moz-landing-system : lando
Depends on D55829
In case other rejects are still using strings instead of error objects.
Differential Revision: https://phabricator.services.mozilla.com/D55830
--HG--
extra : moz-landing-system : lando
I refactored some of the unit tests to see if I'm on the right direction. If so, I'll continue with other unit tests.
Differential Revision: https://phabricator.services.mozilla.com/D55923
--HG--
extra : moz-landing-system : lando
ContentTask tasks have a different lifetime than SpecialPowers tasks, with the
former being tied to the lifetime of a message manager and the latter tied to
the lifetime of a window global. That means that existing ContentTask callers
which expect to be able to register load listeners before the creation of a
window global, or which expect to persist after a page has navigated, won't
work as SpecialPowers tasks.
Since those sorts of tasks are not really resilient in the face of Fission,
they should really be written to work differently, but this patch mostly just
reverts them to using ContentTask for the time being.
Differential Revision: https://phabricator.services.mozilla.com/D53744
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
This revision modifies RDM UI’s `getViewportBrowser` to return the tab’s <browser> instead of the <mozbrowser> this.toolWindow’s [getViewportBrowser method](https://searchfox.org/mozilla-central/source/devtools/client/responsive/index.js#176) returns. If the pref `devtools.responsive.browserUI.enabled` is set to true, this will cause this.toolWindow to be null because this object is set during the [swap step when RDM is initialized](https://searchfox.org/mozilla-central/source/devtools/client/responsive/ui.js#150). Since we're not doing away with swap/tunnel until work on RDM fission is complete, we should still preserve the toolWindow property on RDM UI.
For context, this.toolWindow is a reference to the RDM UI’s window, which also happens to be populated with other properties such as `getViewportBrowser` (the function causing the issue), `getViewportSize`, `addInitialViewport`, etc… It’s responsible for holding the RDM UI chrome:// document which is also where the <mozbrowser> iframe is contained. Please see: https://searchfox.org/mozilla-central/source/devtools/client/responsive/index.js for reference on where these properties are added.
Also, now that the RDM fission work requires the removal of <mozbrowser>, this.toolWindow won't be needed to get access to the toolbar UI. The RDM toolbar will be embedded into the browser UI and can be referenced with `this.rdmFrame`.
So this means toolWindow along with any parts of the code using it should be removed when fission work is complete. I believe [Bug 1585096](https://bugzilla.mozilla.org/show_bug.cgi?id=1585096) would be the correct place to do this.
Differential Revision: https://phabricator.services.mozilla.com/D56602
--HG--
extra : moz-landing-system : lando
For some reason the parameterNames was expected as
a prop, but it's available on the function grip
itself.
The rep is fixed, and tests are modified to reflect
this change.
Differential Revision: https://phabricator.services.mozilla.com/D55926
--HG--
extra : moz-landing-system : lando
For some reason the parameterNames was expected as
a prop, but it's available on the function grip
itself.
The rep is fixed, and tests are modified to reflect
this change.
Differential Revision: https://phabricator.services.mozilla.com/D55926
--HG--
extra : moz-landing-system : lando
The failure indicates that there's a pending call
to the server for highlighting while the connection
is being closed.
I guess that's because the test was logging some
nodes, and the mouse position could trigger a
highlight.
Since we don't really need to log those nodes,
this patch only changes one of the expression.
Differential Revision: https://phabricator.services.mozilla.com/D55782
--HG--
extra : moz-landing-system : lando
This only highlights the fact that the front will only
do the heavy work once, since we set the _client property
to null, and the function is guarded against the _client
truthiness.
Differential Revision: https://phabricator.services.mozilla.com/D56524
--HG--
extra : moz-landing-system : lando
These typically indicate a fatal problem for whatever the page is trying to do;
we should give them the appropriate visibility.
Differential Revision: https://phabricator.services.mozilla.com/D56239
--HG--
extra : moz-landing-system : lando
Backed out changeset 06ca873edb4c (bug 1525966)
Backed out changeset 8ff967efc6d6 (bug 1525966)
CLOSED TREE
--HG--
extra : rebase_source : 8fb6432626ea832ed4bf081068d0c1144de066bd
Depends on D55829
In case other rejects are still using strings instead of error objects.
Differential Revision: https://phabricator.services.mozilla.com/D55830
--HG--
extra : moz-landing-system : lando
This will allow Reps to consume those and
display more accurate functions informations.
Differential Revision: https://phabricator.services.mozilla.com/D55928
--HG--
extra : moz-landing-system : lando
