You'd think that this would throw off the assertion stacks in nsTraceRefcnt::WalkTheStack. But as far as I can tell, it was already setting |skipFrames| too high!
On top of that, the function was getting out-of-lined in some instances already. It really should have been MOZ_ALWAYS_INLINE_EVEN_DEBUG.
MozReview-Commit-ID: J2FZmi0pKro
--HG--
extra : rebase_source : 20e5be9f8c21637a28435f47b8ab2de101825679
Not only does this trim the code, it also makes MOZ_RELEASE_ASSERT follow the advice of MOZ_CRASH earlier in the file:
* If we're a DEBUG build and we crash at a MOZ_CRASH which provides an
* explanation-string, we print the string to stderr. Otherwise, we don't
* print anything; this is because we want MOZ_CRASH to be 100% safe in release
* builds, and it's hard to print to stderr safely when memory might have been
* corrupted.
MozReview-Commit-ID: Kuxzn1v9Vfs
--HG--
extra : rebase_source : 5c6efe7cb9adb1c366b423d6ff8f95002512985c
I left gMozCrashReason visible (but not meaningfully used) in all builds, in order to match the behavior of Assertions.cpp, and to avoid more #ifdef clutter in nsExceptionHandler.cpp.
MozReview-Commit-ID: smoFkddGzd
--HG--
extra : rebase_source : 498f927f62fc944edf254c2ff3b115131367a506
The C versus C++ distinction was only there so that Android could make sure it used the global ::abort. I didn't see the need to maintain the distinction for Windows. (Besides, with this change we're no longer doing textual inclusion of "TerminateProcess" in the macro, so people can't take over the name.)
Linux's abort sequence wasn't long enough to be troublesome, so I left it alone.
MozReview-Commit-ID: Ah5XtWpevGz
--HG--
extra : rebase_source : 37c3fb4c50bcba8e48c6a965a02e3f8608940538
It seems likely that some documents are created in content processes without
a DocAccessibleChild actor because there is no docshell or tabchild
associated with the document. However DocAccessible::DoInitialUpdate()
already calls functions that assume the document is associated with a
docshell. So hopefully trying to create the child actor there will mean it
is more successful.
We aren't likely to implement predictive size decoding for XUL images. So instead do some sync decoding when we Draw them at their specified size. This will avoid a paint where we don't draw the image, or draw it at the wrong size, followed later by the correctly sized image.
This is consistent with GTK not setting these flags with GtkTextView
and GtkScrolledWindow.
The active flag was triggering @selected_bg_color with Ambiance.
This patch almost reverts the state flags to the logic prior to
cd7544affe40 but keeps the focused flag in the scrolled window.
MozReview-Commit-ID: IVY1sI2Hllw
--HG--
extra : rebase_source : 5774af02f7b6abfeab15bee5f35d941490c81514
Based on the other changesets in this series, we don't expect to be calling
UpdateProperties() and ComposeStyle() from within ComposeStyle() itself.
However, in case there is some scenario where that does still occur, we leave
the mIsComposing check in place and add an equivalent MOZ_DIAGNOSTIC_ASSERT so
that we are alerted if this does occur on debug / Nightly / DevEdition builds,
but handle it gracefully on beta or release builds.
MozReview-Commit-ID: 2cFpyMFR29Q
--HG--
extra : rebase_source : 8d6175b8785dd062bda85eda7f06c01bec42fbee
