ExternMozLog treated aMsg as a format, instead of the string being printed.
If it happened to contain any escape sequences, it led to a crash as the parameters weren't there.
Differential Revision: https://phabricator.services.mozilla.com/D92886
- Increase maximum message length
- Ensure that file/line output is using the file:line style such that IDEs and
other tools can easily link it to the source code locations
Differential Revision: https://phabricator.services.mozilla.com/D91239
I gave TraceOptions some implicit consturctors to make it easier to set a
single option by passing an enum value.
Depends on D92595
Differential Revision: https://phabricator.services.mozilla.com/D92596
- onSVGZoom is gone and we no longer dispatch it.
- we've never dispatched SVGUnload or SVGResize events and if we did implement these they would be unload and resize events now.
Differential Revision: https://phabricator.services.mozilla.com/D92381
Currently we have two different enums that determine the tracer kind. Combine
this into a single enum and move it to the JS namespace.
Differential Revision: https://phabricator.services.mozilla.com/D92253
The instances of this are called 'actions' everywhere and I think it makes
sense that the type should be called that. Also make it an enum class and move
it into the JS namespace.
Differential Revision: https://phabricator.services.mozilla.com/D92252
The `category.WithOptions(...)` syntax was a bit strange and difficult to explain.
Now the category and options are separate parameters. Default options can be specified with `MarkerOptions{}` or just `{}`.
As a special case, defaulted-NoPayload functions don't need `<>`, and defaulted-NoPayload functions and macros don't even need `{}` for default options, e.g.:
`profiler_add_marker("name", OTHER); PROFILER_MARKER_UNTYPED("name", OTHER);`
Differential Revision: https://phabricator.services.mozilla.com/D91680
The `category.WithOptions(...)` syntax was a bit strange and difficult to explain.
Now the category and options are separate parameters. Default options can be specified with `MarkerOptions{}` or just `{}`.
As a special case, defaulted-NoPayload functions don't need `<>`, and defaulted-NoPayload functions and macros don't even need `{}` for default options, e.g.:
`profiler_add_marker("name", OTHER); PROFILER_MARKER_UNTYPED("name", OTHER);`
Differential Revision: https://phabricator.services.mozilla.com/D91680
No longer reset a moved-from Result to an error state, which required
UnusedZero<E>::GetDefaultValue, which was somewhat confusing, and might
also be inefficient. Leaving Result in a valid state, which might be a
success or error state is sufficient.
Differential Revision: https://phabricator.services.mozilla.com/D91250
In the initial patches for bug 1656526, mhowell noticed that for startups which
take a very long time, if the user interacts with the skeleton UI window, the OS
will flag us as not responsive, which could be a poorer user experience than
seeing nothing. Since our UI is designed to look non-interactive anyway, we
assume that a better experience would be to simply squash the not responsive
response from the OS by trivially processing native events. It's not perfect in,
say, the event that startup is hung for some reason, but it's arguably preferable
to our old model of startup being hung, which was just nothing being displayed at
all.
Differential Revision: https://phabricator.services.mozilla.com/D91005
Virtual keyboard on Android (and API level of GTK) supports autocapitalization
that is automatically capitalize words and etc.
atucapitalize attribute inherits from form element if the element is button,
fieldset, input, output, select and textarea. Its tests are included in wpt.
WebKit on iOS and Blink on Android already support this HTML attribute, so I
would like to support this on Firefox/GeckoView Nightly.
Differential Revision: https://phabricator.services.mozilla.com/D86674
We want to collect information on late writes via telemetry. We have been
doing this in Nightly for a while now, but want to do so in beta/release. I
was actually initially unaware of this limitation of the IOInterposer, but
we need the IOInterposer to collect information on late writes, so I would
like to enable it for just early beta, in the hopes that we can catch any
late writes that may be happening, without adding a performance tax onto
release.
Accordingly, is perf the only reason that this was restricted to Nightly?
And if so, did we measure a perf difference, or was this just general
caution regarding the performance impact? Is there anything else to look
out for?
Differential Revision: https://phabricator.services.mozilla.com/D90894
Among other things, there were some misuses of std::forward, and
GenericErrorResult was (presumably accidentally) instatiated with
references as the template argument type, e.g. const nsresult&,
which circumvented the check for not calling it with NS_OK in
ResultExtensions.h
Differential Revision: https://phabricator.services.mozilla.com/D90561
Among other things, there were some misuses of std::forward, and
GenericErrorResult was (presumably accidentally) instatiated with
references as the template argument type, e.g. const nsresult&,
which circumvented the check for not calling it with NS_OK in
ResultExtensions.h
Differential Revision: https://phabricator.services.mozilla.com/D90561
The RDD process gets shutdown following a NS_XPCOM_SHUTDOWN_OBSERVER_ID notification.
Notifications are processed in LIFO order, since the RDD process is started on demand it would have typically be registered after a content process.
We must ensure that the RDD get shutdown after all content processes so that it can receive notifications that the RemoteDecoderManagerChilds are shutting down.
Differential Revision: https://phabricator.services.mozilla.com/D90485
The RDD process gets shutdown following a NS_XPCOM_SHUTDOWN_OBSERVER_ID notification.
Notifications are processed in LIFO order, since the RDD process is started on demand it would have typically be registered after a content process.
We must ensure that the RDD get shutdown after all content processes so that it can receive notifications that the RemoteDecoderManagerChilds are shutting down.
Differential Revision: https://phabricator.services.mozilla.com/D90485
I've wanted to use this recently for a couple things. This uses the
same scheme and even templates we use for attributes, so it's mostly
moving code around...
Inverting the code generation so that the implementation is infallible,
and we actually generate the NS_IMETHOD goop inline somehow could be
potentially desirable, though that causes an extra virtual call for
non-C++ callers I guess, so maybe it's not such a great trade-off. Plus
it seems more complicated...
Explicitly forbid mixing infallible with notxpcom (as it doesn't make
sense), and similarly forbid infallible + returning void (as C++ doesn't
allow us to overload a function that differs only on its return type).
Differential Revision: https://phabricator.services.mozilla.com/D90044
This will allow resolving DOM promises with non-wrappercached XPIDL interfaces
in a more convenient manner, as the wrapped JS object will have more concrete
interface information without needing to invoke QueryInterface.
Differential Revision: https://phabricator.services.mozilla.com/D87002
When I originally wrote rust-xpcom support, it wasn't possible to implement
generic vtables in Rust. With updates and improvements to the language since
then, it is now possible to do, so this patch adds support for implementing
xpcom interfaces on generic structs.
All generic parameters to these structs are required to have a `'static`
lifetime bound, as it is not possible to safely represent xpcom interface
objects which contain internal non-'static references.
Differential Revision: https://phabricator.services.mozilla.com/D89950
This backs out all work from bug 1627075 as well as all of its
descendents. There were a few conflicts when backing this out but
overall it was pretty clean, so I would say it's a fairly mild
level of risk. Historically Nathan Froyd has reviewed these patches,
but he is no longer at Mozilla, and no one else is particularly
familiar with the code, so I am passing this off to RyanVM who has
at least been familiar with the history of the bug.
Differential Revision: https://phabricator.services.mozilla.com/D90096
In most situations, JSONWriter users already know string lengths (either directly, or through `nsCString` and friends), so we should keep this information through JSONWriter and not recompute it again.
This also allows using JSONWriter with sub-strings (e.g., from a bigger buffer), without having to create null-terminated strings.
Public JSONWriter functions have overloads that accept literal strings.
Differential Revision: https://phabricator.services.mozilla.com/D86192
Previously, this code used a &'static T in order to get the null pointer
optimization. Since the code was written, `NonNull` has been stabilized, and now
should be used instead.
Differential Revision: https://phabricator.services.mozilla.com/D89947
The name `AUTO_PROFILER_MARKER_TEXT` is more consistent with the equivalent non-`AUTO` macro, and similarly arguments have been re-ordered to be the same, i.e.: Name, category&options, text.
The different macros with different argument sets can now be collapsed into one macro, and the optional arguments (timing, inner window id, backtrace) can easily be added to the `MarkerOptions` where needed.
As a bonus, a specific start time can optionally be provided at construction time.
Differential Revision: https://phabricator.services.mozilla.com/D89588
Mostly mechanical change, with some extra work where non-literal names are provided.
Also, when this is the only profiler call in a file, `#include "GeckoProfiler.h"` can be changed to `#include "mozilla/ProfilerMarkers.h"`.
Differential Revision: https://phabricator.services.mozilla.com/D89415