This was a difficult situation. We are not waiting for a server response when setting or
removing breakpoints. The result is that the server has not completed those actions by the time the
test closed, leaving setBreakpoint or removeBreakpoint requests hanging, causing a number of tests
to fail. In order to get around this, I made the panel action "SET_BREAKPOINT" and
"REMOVE_BREAKPOINT" aware of the server response. This involved rewriting the helper methods
`clientSetBreakpoint` and `clientRemoveBreakpoint` so that they no longer relied on the dispatch.
It was not possible to use the dispatches to wait, as they had no event exposed to the tests,
especially in cases when we triggered these requests via button presses.
Differential Revision: https://phabricator.services.mozilla.com/D32710
--HG--
extra : moz-landing-system : lando
this is the weird one. we have a Debugger.executeSoon call for the destruction of the host.
However, before this happened immediately after the test closed. Now, it happens a little later, and
this messes up the data set up. The comment says that we cannot remove this.
Differential Revision: https://phabricator.services.mozilla.com/D32722
--HG--
extra : moz-landing-system : lando
In order for a front to be available to getFront on a given target, it must be first --
registered on the target scope, and second -- set on the target's targetForm. This makes that update
for both browsing context and worker targets. This works as part of a work around until we can get
the server into better shape.
Differential Revision: https://phabricator.services.mozilla.com/D32698
--HG--
extra : moz-landing-system : lando
The resume case is much more complex than the other events, because we do an
unsafeSynchronize to send an unsolicited pause. In the old system, the resume response would have
been ignored, but that is no longer the case. With the new system, we do not want to send a response
to a resume action if it did not come from the UI. This also update the debugger panel code to
accept a resume.
Differential Revision: https://phabricator.services.mozilla.com/D32697
--HG--
extra : moz-landing-system : lando
This patch removes the preference we were using to
display the checkbox in the Browser Console; it's now
always displayed there.
Differential Revision: https://phabricator.services.mozilla.com/D34996
--HG--
extra : moz-landing-system : lando
In an attempt to reduce intermittent failures, the pref apz.keyboard.enabled is set to false. However, this preference is only ever read once, on startup before any JS test has a chance to run and modify the pref..
It doesn't do what it was thought to do.
Differential Revision: https://phabricator.services.mozilla.com/D34860
--HG--
extra : moz-landing-system : lando
This was a difficult situation. We are not waiting for a server response when setting or
removing breakpoints. The result is that the server has not completed those actions by the time the
test closed, leaving setBreakpoint or removeBreakpoint requests hanging, causing a number of tests
to fail. In order to get around this, I made the panel action "SET_BREAKPOINT" and
"REMOVE_BREAKPOINT" aware of the server response. This involved rewriting the helper methods
`clientSetBreakpoint` and `clientRemoveBreakpoint` so that they no longer relied on the dispatch.
It was not possible to use the dispatches to wait, as they had no event exposed to the tests,
especially in cases when we triggered these requests via button presses.
Differential Revision: https://phabricator.services.mozilla.com/D32710
--HG--
extra : moz-landing-system : lando
this is the weird one. we have a Debugger.executeSoon call for the destruction of the host.
However, before this happened immediately after the test closed. Now, it happens a little later, and
this messes up the data set up. The comment says that we cannot remove this.
Differential Revision: https://phabricator.services.mozilla.com/D32722
--HG--
extra : moz-landing-system : lando
In order for a front to be available to getFront on a given target, it must be first --
registered on the target scope, and second -- set on the target's targetForm. This makes that update
for both browsing context and worker targets. This works as part of a work around until we can get
the server into better shape.
Differential Revision: https://phabricator.services.mozilla.com/D32698
--HG--
extra : moz-landing-system : lando
The resume case is much more complex than the other events, because we do an
unsafeSynchronize to send an unsolicited pause. In the old system, the resume response would have
been ignored, but that is no longer the case. With the new system, we do not want to send a response
to a resume action if it did not come from the UI. This also update the debugger panel code to
accept a resume.
Differential Revision: https://phabricator.services.mozilla.com/D32697
--HG--
extra : moz-landing-system : lando
For content HTML/XHTML copy/paste should always be enabled, but for chrome
docs we can support enabling/disabling copy/paste.
Also, restores tests to how they were before copy/paste was always enabled.
Differential Revision: https://phabricator.services.mozilla.com/D34805
--HG--
extra : moz-landing-system : lando
The `WebProgress#sendLoadCallResult` method only existed to send a empty async
message and was only called from the `WebNavigationChild`. Since
`WebNavigationChild` is in the process of being removed, it makes sense to
inline the replaced method into its call site.
Differential Revision: https://phabricator.services.mozilla.com/D34566
--HG--
extra : moz-landing-system : lando
- Fixes expandFrames() to ensure the thread property is set
- Refactors getSourceLocationFromMouseEvent to use fromEditorLine
- Replaces dwarf_to_json (for proper DWARF conversion)
Differential Revision: https://phabricator.services.mozilla.com/D33092
--HG--
extra : moz-landing-system : lando
The `WebProgress#sendLoadCallResult` method only existed to send a empty async
message and was only called from the `WebNavigationChild`. Since
`WebNavigationChild` is in the process of being removed, it makes sense to
inline the replaced method into its call site.
Differential Revision: https://phabricator.services.mozilla.com/D34566
--HG--
extra : moz-landing-system : lando
This implements Victoria's suggestion for improving highlight line visibility.
Differential Revision: https://phabricator.services.mozilla.com/D34372
--HG--
extra : moz-landing-system : lando
In the regular webconsole input, on Enter, we check that the
input is a compilable unit, so the user don't accidentally
execute an incomplete snippet.
In the editor mode, the user will have to use Ctrl/Cmd + Enter to
execute, so we don't have to worry about Enter (it will simply
append a new line).
And since the user might deal with a large number of characters,
we don't want to prevent them to execute. If it's malformed, they
will get an error in the output and can fix their input easily, since
it wasn't cleared.
The patch adds a test to ensure this work as expected.
Differential Revision: https://phabricator.services.mozilla.com/D34522
--HG--
extra : moz-landing-system : lando
This test was failing due to the tab closing before a response from the tab was recieved.
It is due to the threadClient closing more quickly. This waits for the last message before closing
Differential Revision: https://phabricator.services.mozilla.com/D32718
--HG--
extra : moz-landing-system : lando
this test was failing because the threadClient was posting messages due to being unable to
find the source map. After investigating, I found that the sourcemap was formatted incorrectly. I do
not know if this was intentional. If it wasn't this fix works. If it was, then we need to find a way
to wait on source map failures, and the test name might need to be updated
Differential Revision: https://phabricator.services.mozilla.com/D32715
--HG--
extra : moz-landing-system : lando
the test `browser_net_params_sorted` may not have been functioning for some time. While
investigating this, I discovered that we were getting an empty array for `actualKeys`. Iterating
over this array returned immediately. As a result the test always passed, even though the shape of
the data changed. I updated this code so that it waits for the dom to be populated with the number
of keys expected. I also updated the test to reflect the data the front end has today.
Differential Revision: https://phabricator.services.mozilla.com/D32713
--HG--
extra : moz-landing-system : lando
There were a few miscellaneous situations in which the test would fail due to a hanging
request. These tests passed in the past because the old way of using the threadActor did not
identify which requests had been responded to.
Differential Revision: https://phabricator.services.mozilla.com/D32711
--HG--
extra : moz-landing-system : lando
In the layout panel of the inspector, in the flex part, change color of min and max properties.
Change the min/max labels, and lock icon color of the flex outline box to the same color too.
Differential Revision: https://phabricator.services.mozilla.com/D33835
--HG--
extra : moz-landing-system : lando
If logpoint throws, set `level` to "error".
Add tests to ensure the correct level is set.
Demo function: https://luxuriant-system.glitch.me/
Add some logpoints. The first two statements are invalid. The third one is valid.
{F1311386}
In console:
{F1311387}
Differential Revision: https://phabricator.services.mozilla.com/D31157
--HG--
extra : moz-landing-system : lando
Added proper plural form to editor.searchResults and sourceSearch.resultsSummary1. Updated the comments and IDs for the new strings as well. Replaced all instances of old string references with new string references.
Differential Revision: https://phabricator.services.mozilla.com/D32881
--HG--
extra : moz-landing-system : lando
