As devtools become optional, nsContextMenu needs to check if devtools are installed before
displaying the devtools-related menu entries.
Rather than loading devtools classing and calling APIs, use APIs provided by the DevToolsShim,
that will stay in mozilla-central.
MozReview-Commit-ID: CxqabTjhckC
--HG--
extra : rebase_source : 1781edcf11316eab7e95cbab834d1bc3230c44d7
Keyboard navigation was broken because we introduced private columns that are never displayed (for compound primary keys) and were not equipped to deal with hidden key columns.
This change gets the first visible column, whether it is private or not so that we no longer have to worry about hidden key columns.
The small change to the keyboard test ensures that the private column is hidden so the test will fail if this feature is broken again.
MozReview-Commit-ID: IB7efHsflGU
--HG--
extra : rebase_source : 06e3283447a7e91641f3d91058fd472d8ca29e8a
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
The browser-chrome test suite now detects and reports unhandled rejections of native Promises, in addition to those created by Promise.jsm. The whitelisting mechanism is updated to use primarily the PromiseTestUtils.expectUncaughtRejection function. Tests will fail if a rejection that is not whitelisted occurs, or if a whitelisted rejection does not occur anymore.
MozReview-Commit-ID: 1beGB5GG8Ty
--HG--
extra : rebase_source : b6573f8e2001f91d0e5a50f6376b191459549e94
extra : intermediate-source : 0411e687044ecc7b56684196238e6e6e68a9d685
extra : source : 8d53be05afc59519c5ce8cfae96d284a972fda71
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