Those will be consumed by DevTools webconsole so we can order messages
emitted within the same millisecond more precisely (see next patch in queue)
Differential Revision: https://phabricator.services.mozilla.com/D155545
This prevents copies and avoids the hack we have to avoid this, which
right now is using nsDependent{C,}String.
Non-virtual actors can still use `nsString` if they need to on the
receiving end.
Differential Revision: https://phabricator.services.mozilla.com/D152519
The current implementation of TimelineConsumers contains some unnecessary
complexity due to how it is initialized as a singleton, and the need for it to
be initialized and used in a threadsafe way. This patch attempts to simplify it
by making all members static, and removing the need to explicitly observe
shutdown for cleanup.
In addition, this approach avoids the risk of the type being accessed from
off-main-thread during initialization or shutdown.
Depends on D150442
Differential Revision: https://phabricator.services.mozilla.com/D150443
See the comment in the file explaining it. For a case of logging 100k numbers,
this dropped the time per number from 15 microseconds to 9 with the console
closed, and 55 microseconds to 38 with the console open. I think we could shave
off more with a native approach, but I don't know that it's worth it and it's
much more likely for that to introduce bugs.
Differential Revision: https://phabricator.services.mozilla.com/D143782
Depends on D141467
The devtools.enabled preference was never really used in the end.
The devtools add-on plans were cancelled, as well as the devtools onboarding flows.
So I think this was essentially dead code.
Differential Revision: https://phabricator.services.mozilla.com/D141468
Depends on D141467
The devtools.enabled preference was never really used in the end.
The devtools add-on plans were cancelled, as well as the devtools onboarding flows.
So I think this was essentially dead code.
Differential Revision: https://phabricator.services.mozilla.com/D141468
#include "mozilla/dom/WorkerScope.h" is removed from WorkerPrivate.h, where calling WorkerPrivate::GlobalScope() without include "WorkerScope.h" makes WorkerScope as an incomplete type.
Depends on 132800
Depends on D132800
Differential Revision: https://phabricator.services.mozilla.com/D133483
#include "mozilla/dom/WorkerScope.h" is removed from WorkerPrivate.h, where calling WorkerPrivate::GlobalScope() without include "WorkerScope.h" makes WorkerScope as an incomplete type.
Depends on 132800
Depends on D132800
Differential Revision: https://phabricator.services.mozilla.com/D133483
dom/console/Console.cpp:2899:10: error: 'return' will never be executed [-Werror,-Wunreachable-code-return]
return 0;
^
dom/console/Console.cpp:2955:10: error: 'return' will never be executed [-Werror,-Wunreachable-code-return]
return 0;
^
dom/fetch/FetchDriver.cpp:252:10: error: 'return' will never be executed [-Werror,-Wunreachable-code-return]
return NS_OK;
^~~~~
Differential Revision: https://phabricator.services.mozilla.com/D126870
We now set the descriptor's getter or setter when the corresponding argument
to DefineAccessorProperty is non-nullptr.
Usually the flag was passed only if the corresponding object argument was non-nullptr,
so there's no change in behavior for those.
The exception is `Console::PopulateConsoleNotificationInTheTargetScope` where we passed
JSPROP_SETTER with a nullptr setter. Changing this is likely okay; it shouldn't make a
difference for new properties anyway.
Note that code can still use the richer PropertyDescriptor API to set nullptr
getters/setters explicitly.
Differential Revision: https://phabricator.services.mozilla.com/D116091
Bug 1583109 introduced new function templates StringJoin and StringJoinAppend.
These are now used to replace several custom loops across the codebase that
implement string-joining algorithms to simplify the code.
Differential Revision: https://phabricator.services.mozilla.com/D98750
Bug 1583109 introduced new function templates StringJoin and StringJoinAppend.
These are now used to replace several custom loops across the codebase that
implement string-joining algorithms to simplify the code.
Differential Revision: https://phabricator.services.mozilla.com/D98750
To be able to remove SystemGroup, NS_ReleaseOnMainThreadSystemGroup
needs to have its dependency on SystemGroup removed. Since all
releases using SystemGroup would've released on the main thread anyway
we can safely replace NS_ReleaseOnMainThreadSystemGroup with
NS_ReleaseOnMainThread.
Depends on D64390
Differential Revision: https://phabricator.services.mozilla.com/D67631
--HG--
extra : moz-landing-system : lando
Set the flag on the affected classes, which are:
- CallbackTimeoutHandler
- nsJSArgArray
- CallbackObject
- Console
- MessageEvent
- IDBIndexCursor
- ExtendableMessageEvent
- JSPurpleBuffer
Differential Revision: https://phabricator.services.mozilla.com/D68196
--HG--
extra : moz-landing-system : lando
so that references can be released from the main thread and there is no need
to send a message to Console thread.
Depends on D67999
Differential Revision: https://phabricator.services.mozilla.com/D68000
--HG--
extra : moz-landing-system : lando
This provides that ConsoleRunnable no longer has a reference to Console, which
previously needed to be released through a message to the console thread.
Differential Revision: https://phabricator.services.mozilla.com/D67999
--HG--
extra : moz-landing-system : lando
to remove Console instance access from
PopulateConsoleNotificationInTheTargetScope().
Differential Revision: https://phabricator.services.mozilla.com/D67998
--HG--
extra : moz-landing-system : lando
This will support removal of Console class usage from main thread.
Depends on D67993
Differential Revision: https://phabricator.services.mozilla.com/D67994
--HG--
extra : moz-landing-system : lando
Now that ConsoleCallData has nothing to trace, mCallDataStoragePending has no
purpose.
Depends on D67989
Differential Revision: https://phabricator.services.mozilla.com/D67990
--HG--
extra : moz-landing-system : lando
so that all ConsoleCallData members can be destroyed on either thread.
ArgumentData::mArguments hold the same references that
ConsoleCallData::mCopiedArguments held previously. The name change is because
the references are merely stored rather than any deep copy of objects.
Differential Revision: https://phabricator.services.mozilla.com/D67989
--HG--
extra : moz-landing-system : lando
This removes a dependency on JS objects on ConsoleCallData, and a reference to
the arguments on ConsoleProfileWorkerRunnable.
Differential Revision: https://phabricator.services.mozilla.com/D67988
--HG--
extra : moz-landing-system : lando