This causes a number of issues, like bug 1329082, where we don't swap the
message queues of the MSG where we should, and blows up an assert in debug.
MozReview-Commit-ID: 2I3IjfK8L8r
System SVG rendering on Android 6.0 seems to be broken for certain VectorDrawable's:
these three icons were being distorted, only on Android 6. Using a different SVG
converter (an online converter, as opposed to the Android Studio converter),
results in the icons being rendered correctly.
MozReview-Commit-ID: 2INnb0clb54
--HG--
extra : rebase_source : 5b3fd9ca7354855c6ee70594b960f0098c98d974
The tests have to be skipped because Marionette server only allows the
installation of add-ons for Firefox. Once Fennec gets white-listed, it
would be still necessary to copy the to install XPI to the device file
system.
MozReview-Commit-ID: Jr53iCzkZvo
--HG--
extra : rebase_source : 2fef786cf8b114c2cbd002a6d2b37da51fcc8e5b
What you see first is the removal of the line `this._highlightAll = aHighlight;`, which is repeated in the `_setHighlightAll` method.
This line was put here initially to make the test_findbar_events.xul test pass but in fact makes it so that the pref is never set in `_setHighlightAll`!
In other words, we never actually persisted the 'Highlight All' state properly.
Reading further: the `_dispatchFindEvent` attaches some findbar state flags to the event details, including the value of `_highlightAll`.
Even though none of our consumers use it currently (haven't checked if TB does, though), you can cancel further execution of highlighting all ranges.
Since the `_setHighlightAll` doesn't do that kind of processing, but merely makes sure the internal state is up to snuff, is persisted properly and the buttons are updated, I moved it up to be invoked before dispatching the event.
MozReview-Commit-ID: 4BBy4FR1r5c
--HG--
extra : rebase_source : 204e77aaef3cd55886daeb2e0fdef84da1159c68
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: JgTku7J2Vgf
--HG--
extra : rebase_source : 8a10599f4f9412c83f350ff66847c6f0008456c2
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: GiKMQDIihxI
--HG--
extra : rebase_source : 3d47cd863f5ce833e379cf1ad5e065453450ff84
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: JOWNTMMYcDa
--HG--
extra : rebase_source : d6d1331d384ed4704bd1c30407f18d25f452dbb6
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: 9Q6f0WOnzws
--HG--
extra : rebase_source : 6d3e433da36935dc0f08c37b9acc051908604c2c
Wes Kocher
Jan de Mooij
sotaro
Nicolas B. Pierron
Paul Adenot
Lee Salzman
ffxbld
Carsten "Tomcat" Book
Iris Hsiao
Bobby Holley
Ryan VanderMeulen
Kartikaya Gupta
Andrew Halberstadt
Andrzej Hunt
Andrew Swan
Brian Grinstead
Bob Owen
Henrik Skupin
Mike de Boer
Kestrel
Dimi Lee
David Major
Geoff Brown
Xidorn Quan