mDefaultPreventedByChrome is hacky. When PresShell handles Escape key events in fullscreen mode, it prevents default of every Escape key events and dispatch it only into chrome. After that, it check mDefaultPreventedByChrome if at least one call of preventDefault() occurred in chrome. Therefore, if we shouldn't set both mDefaultPreventedByChrome and mDefaultPreventedByContent to true before dispatching an event. This the reason why we need a special method, PreventDefaultBeforeDispatch() is needed for setting only mDefaultPrevented to true.
MozReview-Commit-ID: BPSq68GnWw6
--HG--
extra : rebase_source : f2f963afeba6994cc090efedebc29c0d9334c96d
extra : source : 1012dc095cc1b7236991a7befdbfbf174dc1c1af
compiler-opts.m4's check for `MOZ_CXX_SUPPORTS_WARNING(-W, unreachable-code-return, ac_cxx_has_wunreachable_code_return)` is broken. The C/C++ code that configure emits for MOZ_CXX_SUPPORTS_WARNING() actually contains a -Wunreachable-code-return warning and, thus, doesn't actually detect that clang supports the -Wunreachable-code-return flag.
This configure code in MOZ_CXX_SUPPORTS_WARNING():
AC_TRY_COMPILE([],
[return(0);],
$3="yes",
$3="no")
generates something like:
int main() {
return(0);
; return 0; }
where the second return, automatically emitted by configure, is unreachable and causes a -Wunreachable-code-return warning.
The fix is to remove the redundant return(0) from MOZ_CXX_SUPPORTS_WARNING(). This allows clang's -Wunreachable-code-return flag to be detected, but then -Wunreachable-code-return breaks other configure checks, including third-party libraries' configure checks (in particular jemalloc) that also have redundant `return(0)`. So all the third-party libraries' configure checks would need to be fixed upstream, which seems like more hassle than the value of the -Wunreachable-code-return warnings.
The way functions are being sandboxed in moz.configure land is that
their global namespace is being replaced with a limited and identifiable
dict. And we avoid re-wrapping a function that already received this
treatment.
The problem is that template functions have their global namespace
replaced, and any function that is defined within the template inherits
that global namespace. So when it comes time to wrap those functions
defined in templates with e.g. depends, we detect that they're already
wrapped although they are not, because we look if their global namespace
is of the recognizable type we use when replacing it.
So instead of looking at the global namespace type, keep track of all
functions that are wrapped.
The pref handler class in GeckoPreferences doesn't need a reference back
to GeckoPreferences, so it's better to make it a static class rather
than a (non-static) anonymous inner class, in order to avoid leaking
the GeckoPreferences instance inadvertently.
To avoid confusion, the patch also renames the class to "PrefCallbacks",
because GeckoPreferences already has an unrelated interface named
"PrefHandler".
HomeConfig.java saved a list of events to be sent later in a batch. This
patch makes it save a pair of strings instead, and the strings are later
used to make calls to GeckoAppShell.
The patch also makes two small optimizations. It makes the queue an
ArrayList instead of a LinkedList to save memory. It also makes copying
the queue a swap instead of a true copy.
This allows to use True and False as values given to
set_config/set_define in moz.configure files, while postponing having to
deal with the long tail of things depending on the values from substs
and defines.
Ideally, everything would handle the bools just fine, but there are too
many things involved to deal with this right now: scripts using
buildconfig.{substs,defines}, scripts using ConfigEnvironment (e.g.
process_define_files.py), ConfigEnvironment itself, etc.
Masayuki Nakano
Chris Peterson
Mike Hommey
Daisuke Akatsuka
Nick Fitzgerald
Cykesiopka
Eden Chuang
Jim Chen
JW Wang
Timothy Guan-tin Chien
Jim Mathies
Jeff Muizelaar
Eric Rahm
David Anderson
Heiher
Matthew Gregan
Brian Birtles
Sotaro Ikeda
George Wright
Wes Kocher