This marker option captures a given thread id.
If left unspecified (by default construction) during the add-marker call, the current thread id will be used then.
Differential Revision: https://phabricator.services.mozilla.com/D87244
The main, and only compulsory, marker option is the `MarkerCategory`, which captures the "category pair", as well as the parent category.
Differential Revision: https://phabricator.services.mozilla.com/D88154
The upcoming profiler-specific add-marker function will need to know which `ProfileChunkedBuffer` to serialize to, `profiler_get_core_buffer()` give access to the profiler's buffer, and `CachedCoreBuffer()` keeps it stored in a function-static object.
Differential Revision: https://phabricator.services.mozilla.com/D87256
These string views are similar to `std::string_view`, but they are optimized to be serialized in the profiler buffer, and later deserialized and streamed to JSON.
They accept literal strings, and keep them as unowned raw pointers and sizes.
They also accept any substring reference, assuming that they will only be used as parameters during function calls, and therefore the dependent string will live during that call where these `StringView`'s are used.
Internally, they also allow optional string ownership, which is only used during deserialization and streaming.
This is hidden, so that users are not tempted to use potentially expensive string allocations during profiling; it's only used *after* profiling, so it's less of an impact to allocate strings then. (But it could still be optimized later on, as part of bug 1577656.)
Differential Revision: https://phabricator.services.mozilla.com/D87242
This patch introduces all new files that contain the new markers C++ API and implementation.
They are mostly empty at this time, only including each other as eventually needed, and with `#ifdef MOZ_GECKO_PROFILER` guards.
Rough inclusion diagram: (header <-- includer)
BaseProfilerMarkerPrerequesites.h <-- ProfilerMarkerPrerequesites.h (Useful types: Input string view, marker options)
^ ^
BaseProfilerMarkerDetail.h <-- ProfilerMarkerDetail.h (Implementation details)
^ ^
BaseProfilerMarkers.h <-- ProfilerMarkers.h (Main API)
^ ^--------- ^ ^---------
BaseProfilerMarkerTypes.h | <-- ProfilerMarkerTypes.h | (Common marker types)
^ BaseProfiler.h <-- GeckoProfiler.h (Existing main profiler headers)
Differential Revision: https://phabricator.services.mozilla.com/D87241
This adds the preference, JS shell option, and {ContextOptions,CompileOptions} fields,
but the value isn't read and the code always acts as it's set to true.
Differential Revision: https://phabricator.services.mozilla.com/D88922
Today the docs tell you to directly clone `mozilla-central`, which is a weird departure from what we do in the other per-platform documents for no real reason. Instead, reference the standalone `bootstrap.py` script as we do for Linux and macOS.
Also, do a little scan and replace references to `mozilla-central` with `mozilla-unified` where appropriate.
Differential Revision: https://phabricator.services.mozilla.com/D88051
This patch ensures that our fallback paper list (used for print saving
as PDF) will use PWG standardized names for the paper sizes for GTK
print settings.
Differential Revision: https://phabricator.services.mozilla.com/D88736
Fixes a regression from bug 1661495, which missed to reset the
current content browsing context if the new chrome window isn't
a browser window.
Depends on D88827
Differential Revision: https://phabricator.services.mozilla.com/D88900
If a navigation in the current browser causes a remoteness change,
the current content browsing context needs to be updated.
Differential Revision: https://phabricator.services.mozilla.com/D88827
Since the patch on bug 1652932 landed in Firefox 80 we always
update the current content browsing context and that now only
when switching to a new window. That leads to an unexpected
change of the current window handle, and as such breaks tests.
Differential Revision: https://phabricator.services.mozilla.com/D88771
Since the `dumpStencil` duplicates part of the BytecodeCompiler code, we must
explicitly instantiate the top-level stencil before parse is run. Also add a
test case for this.
Differential Revision: https://phabricator.services.mozilla.com/D88898
If "save to pdf" is the only printer option, we will hide the system dialog, except on mac
that supports saving to PDF in the native dialog.
Differential Revision: https://phabricator.services.mozilla.com/D88362
Before bug 1636728 this couldn't happen because print documents weren't
hosted in an <browser>. The presentation of documents that are being
printed should be managed by the print job.
We should, in fact, probably just make mDocument->IsStaticDocument() the
condition, or such.
Differential Revision: https://phabricator.services.mozilla.com/D88901
This changes most of our automation builds to clang 11.0.0 rc2.
Not included:
* code coverage builds, per bug 1660341
* mingw builds, which have traditionally been on their own update cadence, and in this case are blocked anyway by bug 1658632
This will leave some unused clang-9 task definitions. I intend to clean them up, but at a later date. For now I want to focus on making sure this update sticks, since patches like this have a tendency to bounce.
Differential Revision: https://phabricator.services.mozilla.com/D88313
A few test cases fail under clang-11 on Linux debug builds only. As described in the bug, we unfortunately don't have the bandwidth to investigate, so this patch accepts the failures.
Differential Revision: https://phabricator.services.mozilla.com/D88363
For not-well-understood reasons, ld's `--gc-sections` discards a large number of the PGO bookkeeping structures that enable us to keep track of function counters, and the effect gets worse in object files generated by clang-10.
As much as I'd like to understand this better, the investigations take way too much time. As a path of least resistance, we can disable `--gc-sections` for the instrumentation phase of PGO builds. It won't harm anything since users never see those builds, and it will improve the performance of the optimized phase greatly.
Differential Revision: https://phabricator.services.mozilla.com/D78112
1. The data sent from `HttpBackgroundChannelParent` to `HttpBackgroundChannelChild` is using type `nsDependentCSubstring`, since I'd like to reduce one copy in parent process.
2. The data sent from `HttpTransactionChild` to `HttpTransactionParent` is using type `nsCString`. The main reason is that the data is actually captured in `HttpTransactionParent::RecvOnDataAvailable` [1] and put in channel event queue. If we use `nsDependentCSubstring` here, the data would be copied in parent process.
3. In `HttpBackgroundChannelChild::RecvOnTransportAndData`, it's inevitable that the data is copied when assigning the data to a `nsCString`, since sometimes `HttpBackgroundChannelChild::RecvOnTransportAndData` needs to be queued and execute later.
[1] https://searchfox.org/mozilla-central/rev/969fc7fa6c3c7fc489f53b7b7f8c902028b5169f/netwerk/protocol/http/HttpTransactionParent.cpp#556
Differential Revision: https://phabricator.services.mozilla.com/D88781
Allow 3 showing of import suggestions debouncing multiple impressions within 10 seconds. Also treat deleting a suggestion as opt-out.
Differential Revision: https://phabricator.services.mozilla.com/D87805
It seems that VoiceOver expects AXDescriptionList and AXDescription
as subroles in order to report the correct number of items in a dl.
Differential Revision: https://phabricator.services.mozilla.com/D88890
Now that we've concluded no immediate action is needed for slow
ShellExecuteByExplorer, `SHELLEXECUTEBYEXPLORER_DURATION_MS` is
no longer needed.
Differential Revision: https://phabricator.services.mozilla.com/D86143
During scrolling, the caret's position relative to the
custom-content-container (cached in mImaginaryCaretRectInContainerFrame)
may not change, but its position relative to root frame can (cached in
mImaginaryCaretRect).
We need to update mImaginaryCaret each time we are in SetPosition().
Otherwise, the caret still remembers its pre-scrolling old position next
time when we drag it, resulting the caret jumping to its old
pre-scrolling position suddenly.
Note this bug only occurs on the root scroll frame where the APZ is
enabled, not in any sub-scroll frames where APZ is disable when the
caret is shown.
Differential Revision: https://phabricator.services.mozilla.com/D88638
If a navigation in the current browser causes a remoteness change,
the current content browsing context needs to be updated.
Differential Revision: https://phabricator.services.mozilla.com/D88827