This ensures that clicking on a message open the netmonitor panel, with the network
item clicked being selected in the netmonitor panel.
The loadDocument was edited to accept a URL instead of relying on the existence of
a TEST_PATH variable. Callsites where thus modified.
MozReview-Commit-ID: 3dbX1Myxirz
--HG--
rename : devtools/client/webconsole/test/test-network-request.html => devtools/client/webconsole/new-console-output/test/mochitest/test-network-request.html
extra : rebase_source : 06eac0cad3eba9961b61f1a2df2f2932c60dd2bc
Prior to this patch, we were retrieving the message data in the ConsoleOutput
render, for each message. This means that for each message addition, we were
retrieving the data for each message in the store.
This doesn't impact performance if there are not many messages in the store, but
if the store is "full", we might end up calling the function to get those messages
a lot. And since the messages are in an Immutable.OrderedMap, it can be very costly.
Moving the retrieval of the message data in ConsoleOutput allow us to only call this
function when a message is added or updated, which allow us to save some time on
the rendering path.
MozReview-Commit-ID: S4NSSW5Mvw
--HG--
extra : rebase_source : 5262b5b34bb86fec5c14b7056875b8f8b661262a
Changes to Promise tests designed to test .then(null) have been reverted, and the browser/extensions directory was excluded because the projects it contains have a separate process for accepting changes.
MozReview-Commit-ID: 1buqgX1EP4P
--HG--
extra : rebase_source : 3a9ea310d3e4a8642aabbc10636c04bfe2e77070
Add a test case to measure streaming time when the store already hit the log limit so
we can have data about pruning.
Switch to performance.mark and performance.measure for time measurement instead of the
custom timeit function we had.
This allow us to have precise data, and also those are written in the profile and then
shown in perf-html, so we can have a better overview of what's going on during the test.
MozReview-Commit-ID: 2nNmukxmUso
--HG--
extra : rebase_source : c8dca67060c2bf6a61e32c78e9fb35b24d7801a9
Add a test case to measure streaming time when the store already hit the log limit so
we can have data about pruning.
Switch to performance.mark and performance.measure for time measurement instead of the
custom timeit function we had.
This allow us to have precise data, and also those are written in the profile and then
shown in perf-html, so we can have a better overview of what's going on during the test.
MozReview-Commit-ID: 2nNmukxmUso
--HG--
extra : rebase_source : 298387e0f33ff226f6d096fd8786f29ddbd5a56f
In the process of adding those tests, I realized the cleanup was
not effective. There were some bugs for Immutable List (we can't
use delete in a withMutation callback), and in object/arrays (we
we're using Array.includes with another array as a parameter).
These were fixed, and the new tests are now passing.
MozReview-Commit-ID: NrKjLuu25
--HG--
extra : rebase_source : cdbdfdc7f5b2a1e3c71cb76cfcd42db5204332ff
In the console, we were assuming that eventTiming was the last
of the eight networkUpdate that happen for a given network request.
Unfortunately, we can't ensure the order in which those updates come,
so the test was intermitently failing when eventTiming was fired
before other updates.
To fix this, we don't look for a specific update, but rather check that
all of the 8 updates happened.
MozReview-Commit-ID: Iv0TIHoqkyv
--HG--
extra : rebase_source : 129a2edd1725e8eddc8ea20de3d38e1bc5f27f87
This moves network update messages to their own property on the store.
We take this as an opportunity to only dispatch the last network update,
i.e. `eventTimings` since it has all we need and saves us some time (there
are 8 network update per network messages, which can be costly).
MozReview-Commit-ID: 2AQN3IlgHg7
--HG--
extra : rebase_source : 465ed3a20c6c202fccf0af9f57f36dcd63db04e6
The idea is to allow tests to set their own logLimit without
having to use Services.setIntPref.
To do so, we also need to not retrieve the logLimit from Services
in the messages reducer. Since we already have the logLimit in the
store, we can retrieve it directly from the store by passing the
prefs state to the messages reducer.
We take this as an opportunity to revisit the createRootReducer function
to be future proof: if any new reducer is added, they should just work
as if we were using combineReducers.
With those changes, we can set a lower logLimit in some tests that used
to have a defined timeout since they were taking too much time.
MozReview-Commit-ID: 7j80XoKkJ1y
--HG--
extra : rebase_source : 23b86faa00d08a80f2cb21291c0df3b4c8113e73
The parent commit did some changes to the architecture of the store that
needed to be handled on the limit messages function.
We take advantage of this to rewrite the functions involved to be as efficient
as possible. To do that, we limit the work done by Immutable structures by doing
changes in them only once per added messages.
MozReview-Commit-ID: 6VzobhWzK40
--HG--
extra : rebase_source : 37a8159401763c07244f6495a28d64406f7bff0a
We used to do the filtering on the selector, which can be costly because
we're looping through all the messages of the store on each new message.
Moving the logic to the reducer allow us to be more thoughtful about which
messages to evaluate and when.
In order to make this change, we need to pass the filter state to the message
reducer. This is done by ditching the combineReducers helper function and do
the plumbing by ourselves, which isn't complex.
MozReview-Commit-ID: Lw37XgEFf7e
--HG--
extra : rebase_source : 290c315b91896765f3a249fbf75449cfa66a710f
Since the FilterButton component is now only a function that returns a React Element,
it looks like Enzyme can't do the comparison we were doing before.
Checking directly the resulting html, even if non-optimal, fixes the test.
MozReview-Commit-ID: 5fAk8WyYCaF
--HG--
extra : rebase_source : 9f15782b64657eb6a31eefcabbcf9775d706cc07
Since the FilterButton component is now only a function that returns a React Element,
it looks like Enzyme can't do the comparison we were doing before.
Checking directly the resulting html, even if non-optimal, fixes the test.
MozReview-Commit-ID: 5fAk8WyYCaF
--HG--
extra : rebase_source : bcf5950bbf2fb63c0a2ff1a99f578eea99379745
The whitelisting function thisTestLeaksUncaughtRejectionsAndShouldBeFixed was replaced by expectUncaughtRejection, and existing calls did not take effect anymore.
MozReview-Commit-ID: 3uOxkgWYWEz
--HG--
extra : rebase_source : 5a10a3ebbfe0ce2a801330041f95447c313a9a70
extra : source : 6f0394b523a66dab444b8551deb8f3c6c81d8f31
The whitelisting function thisTestLeaksUncaughtRejectionsAndShouldBeFixed was replaced by expectUncaughtRejection, and existing calls did not take effect anymore.
MozReview-Commit-ID: 3uOxkgWYWEz
--HG--
extra : rebase_source : 3a7720091180a770b32b595f8094c0d20170166d