This patch includes multiple changes cleaning up various aspects of the crash
reporter client and exception handler:
* Some Unix-specific code was moved out from the base crashreporter client
code and into the appropriate platform implementation
* Functions used to open files in the crashreporter client now accept C++
`std::ios` flags instead of unreadable booleans
* Useless character conversion routines were removed from the
minidump-analyzer
* Crash annotations are not serialized into a huge string anymore every time
they change. They are all written out individually during an exception.
* `WriteEscapedMozCrashReason()` uses the exception-safe `my_strlen()` instead
of plain `strlen()`
* The Windows-specific DLL-blocklist shutdown was removed from the Linux &
macOS Breakpad callbacks
* The `CrashReporterHost`, `CrashReporterClient` and
`CrashReporterMetadataShmem` classes now take `nsACString` references
instead of `nsCString` ones since they never modify their contents
Differential Revision: https://phabricator.services.mozilla.com/D33267
--HG--
extra : moz-landing-system : lando
I'd claim that we don't need it because, in order to enqueue the event, we
already need to have overflowed the event in a normal reflow.
For now this should not break anything (or anything that wasn't already racy
depending on when we paint).
The only reason the flush is there is according to roc is to decide whether to
fire the event, and because it needs the layout information:
https://bugzilla.mozilla.org/show_bug.cgi?id=771822#c4
In practice, however, all the layout information we need we have already
computed by the time we post the event.
We don't expose the rects via the event details, which is what could get
out-of-date, so this patch could only mean that we fire the event slightly more
often in cases where people remove stuff from the DOM, right after we do layout
and the content has overflowed. But that's actually pretty unlikely.
This event in general is pretty problematic because it exposes when we do
layout and when we paint, which is not great. Its test coverage is also pretty
low (test_overflow_event.html, which of course still passes without this).
I still want to do this change first since it's trivial to back out if needed.
Then I'd want to change how it fires to match the scrolled area change event
(which would allow us to remove the WillPaintObserver stuff), after verifying
that chrome consumers are still fine with that, and then put behind a pref and
hide it from content, while we leave time for chrome consumers to migrate away
from it, and allow us to revert if something breaks.
Differential Revision: https://phabricator.services.mozilla.com/D5082
--HG--
extra : moz-landing-system : lando
recordFrames has been wallpapering these flickers because the function ends up
calling FlushPendingNotifications in AsyncScrollPortEvent::Run() and we hadn't
noticed the wallpaper until we tried to remove the FlushPendingNotifications in
AsyncScrollPortEvent::Run().
Differential Revision: https://phabricator.services.mozilla.com/D33226
--HG--
extra : moz-landing-system : lando
Key features in this commit:
- support for `contentfulSpeedIndex` visual metric
- support for the Gecko Window Recorder (Desktop only)
- support for the Gecko Profiler (Desktop only)
- partial support for GeckoView on Android
Differential Revision: https://phabricator.services.mozilla.com/D32907
--HG--
extra : moz-landing-system : lando
The 3-tier PGO builds used a separate mozconfig called 'profile-use' for
the final tier. This created a problem when it rode to beta, since the
same mozconfig was used for all trees, which meant we ended up with
nightly branding on beta builds.
With the PGO-enabling logic in common mozconfigs, we can enable it by
setting the MOZ_PGO_PROFILE_USE environment variable from the task
definition. All of the final-tier PGO builds now use the nightly, beta,
etc mozconfigs like before, so branding should be intact.
Differential Revision: https://phabricator.services.mozilla.com/D33172
--HG--
extra : moz-landing-system : lando
We want to ensure the RDM browser's outer window sizes are not affected as the page is zoomed in or out. In the context of RDM, the size of the browser window will be the same as the viewport so I believe it's safe to assume that the window's outer size will be equal to its inner size when the zoom level is set to 100%.
I found we can get this value by using the presentation context's `GetDeviceZullZoom` method and applying it to the inner sizes of the RDM viewport.
Differential Revision: https://phabricator.services.mozilla.com/D32778
--HG--
extra : moz-landing-system : lando
support for from-font listed in the CSS spec will be implemented in a later bug
Differential Revision: https://phabricator.services.mozilla.com/D33233
--HG--
extra : moz-landing-system : lando
PSM has two instances of TLS bookkeeping structures ("SharedSSLState"): a
"public" one for most connections and a "private" one that automatically clears
its state when the last private browsing context (usually a window) closes.
Since we moved to separating connections by origin attributes, the latter is
largely redundant because keying by origin attributes already separates
connections from different contexts, even when using the "public" shared TLS
state structure. However, it still has the advantage of clearing its state when
the last private browsing context closes. This patch updates the decision of
which SharedSSLState to use by taking into account origin attributes. That is,
if the origin attributes of the connection has a private browsing ID that isn't
the default (unset), we'll use the auto-clearing SharedSSLState. This has the
effect of auto-clearing cached client auth certificate state for private
contexts when the last private browsing window closes. It also clears
accumulated TLS intolerance state in the private context, but that isn't as
relevant any more since we don't do TLS fallback by default.
Differential Revision: https://phabricator.services.mozilla.com/D33099
--HG--
extra : moz-landing-system : lando
Mutating Debugger state between the time a callback-triggering event is
reported to js::Debugger::onSomeEventSlowPath and the time the
callback is actually called can invalidate assumptions, and multiple Debuggers
are a way to do that, part 183.
Differential Revision: https://phabricator.services.mozilla.com/D32242
--HG--
extra : moz-landing-system : lando
Only gtk returns failure ever, and nobody checks the result anyway.
Use an enum class so that it's clear from the caller what it means.
Differential Revision: https://phabricator.services.mozilla.com/D32353
--HG--
extra : moz-landing-system : lando
BindContext was going to have way more information at first, but then I realized
that most of the things I wanted to know were basically a flag away using the
parent node.
Still I think it's worth it, now experimenting with BindToTree will only mean
adding a field to a struct that's included from a couple cpp files, instead of a
massive pain.
I also think this is clearer, and doing this highlights quite a few
inconsistencies in our code which I've left untouched, but commented with
FIXMEs.
Steps are:
$ for file in $(rg 'nsresult BindToTree\(' | cut -d : -f 1 | sort | uniq); do sed -i 's#nsresult BindToTree(Document\* aDocument, nsIContent\* aParent,#nsresult BindToTree(BindContext\&, nsINode\& aParent)#g' $file; done
$ for file in $(rg 'nsresult BindToTree\(' | cut -d : -f 1 | sort | uniq); do sed -i 's# nsIContent\* aBindingParent) override#override#g' $file; done
$ for file in $(rg '::BindToTree\(' | cut -d : -f 1 | sort | uniq); do sed -i 's#::BindToTree(Document\* aDocument, nsIContent\* aParent,#::BindToTree(BindContext\& aContext, nsINode\& aParent)#g' $file; done
$ for file in $(rg '::BindToTree\(' | cut -d : -f 1 | sort | uniq); do sed -i 's#nsIContent\* aBindingParent)##g' $file; done
$ for file in $(rg '::BindToTree\(' | cut -d : -f 1 | sort | uniq); do sed -i 's#::BindToTree(aDocument, aParent, aBindingParent)#::BindToTree(aContext, aParent)#g' $file; done
$ ./mach clang-format
Then manual fixups.
Depends on D32948
Differential Revision: https://phabricator.services.mozilla.com/D32949
