Before, --enable-dmd implied --enable-jemalloc. If --enable-stylo was
also set, it tried to imply --enable-jemalloc=moz. Configure barfed
due to setting the value twice.
The commit refactors the logic for implying the --enable-jemalloc value
to set the proper value depending on the state of dmd and stylo.
MozReview-Commit-ID: 1wKE9Cs1Umt
--HG--
extra : rebase_source : 03acfc386fa9c86ae90e0feb5dae092ea5897179
The bug referred to in the comment was fixed 6 years ago.
The includes in cgen.py are unused.
--HG--
extra : rebase_source : f4521112ee3f2280836ac7030b25ddcba2321eda
AKEYCODE_BACK should be remapped from "BrowserBack" to "GoBack".
AKEYCODE_DPAD_CENTER should be remapped from "Accept" to "Enter".
AKEYCODE_CAPTIONS should be remapped from "Subtitle" to "ClosedCaptionToggle".
The new values are same as Chromium and they are also declared in the spec.
FYI: Gaia doesn't use above key values, so, it's safe to use KEY_MAP_ANDROID for them.
MozReview-Commit-ID: AJwhB59cKzq
--HG--
extra : rebase_source : 8fc923647ee92b39a3317c36fa306f555ddfe2c8
First, we should get rid of "Unidentified" keys which are mapped to specific value on Chromium and we can agree without any discussion.
MozReview-Commit-ID: C4TZzndahNM
--HG--
extra : rebase_source : 5e9d7527c4109049a44391fca45f2ffbd0f81960
I mapped AKEYCODE_ASSIST to "Help". However, Chromium doesn't map the keycode to anything. Additionally, Android has a new keycode AKEYCODE_HELP and Chromium maps it to "Help". So, we should use Chromium's mapping for it.
MozReview-Commit-ID: 19zTP0xclYI
--HG--
extra : rebase_source : c6e5d9f7572b496e4766159aa281088571b11d91
This removes findCertByNickname, findEmailEncryptionCert, and
findEmailSigningCert.
MozReview-Commit-ID: KOxWHJm3GNX
--HG--
extra : rebase_source : c67a65ce71b25c6502bad012c48aa1c30e71f334
This obviates some uses of nsIX509CertDB.findCertByNickname. Other uses are
replaced by equivalent functionality.
MozReview-Commit-ID: 5NCy9mww560
--HG--
extra : rebase_source : cc8506da86e86ae2edef1309e3eb2fddbf8f757e
In general, any code that was using nsIX509Cert.nickname should be able to use
the attribute displayName (if using nickname for display purposes) or the
attribute dbKey (if using nickname as a unique identifier for a certificate).
MozReview-Commit-ID: G9CfMJDfLqe
--HG--
extra : rebase_source : 1c464dab8f028568cedd5a42cf87428b8bb63fc0
This patch makes the following changes:
1. renames nsIX509Cert.windowTitle to displayName
2. removes (most of*) displayName's use of the NSS certificate nickname API
3. adds additional fields that displayName will attempt to use to find a good
name to return (namely, organizationalUnitName and organizationName)
*except for built-in roots, where we have a good hard-coded value for the name
MozReview-Commit-ID: Bt864GnOu7D
--HG--
extra : rebase_source : 5d85aaf68fd4fbe563596354a5ed50e541689934
Fix a crash in GeckoBundle.fromJSONObject due to wrong values array
type. Also, fix a bug where the first element of a converted array is
repeated. r=me for trivial patch.
Notes:
* In CSSAlignUtils.h, I'm just adding a forward-decl for a type used there.
* RubyUtils.h needs to #include nsIFrame.h -- a forward-declare won't
suffice -- because it makes a nsIFrame method-call ("aFrame->GetType()").
* ScrollSnap.h uses the "Maybe" type and a unit defined in
nsIScrollableFrame.h; hence it needs both of those headers.
MozReview-Commit-ID: KuhJVh9RTjZ
--HG--
extra : rebase_source : 062c1abfe9a1efeb7e241f38302c140075d2ae88
These newly-included headers' types are all used directly in the affected files.
MozReview-Commit-ID: 5NEA1QhSJKN
--HG--
extra : rebase_source : 3a9244fcb2a074df1c929de800ddd6cbc1f730e8
(The only reason this isn't triggering a compile error is due to .cpp files'
"using namespace mozilla" getting haphazardly shared via unified builds.)
MozReview-Commit-ID: 1zhJueMWOav
--HG--
extra : rebase_source : d08f18573d823968f654491e61428aa70a4c217c
This adds 2 "using namespace mozilla" (to provide various types),
and 2 "using namespace mozilla::gfx" (to provide mozilla::gfx::DrawTarget).
MozReview-Commit-ID: 2bXbMlr4Dbn
--HG--
extra : rebase_source : 9884419f08529469f23e3fc306ce6e4c57640f0d
The class definition (in the header file) is already inside the namespace. But
the method implementations are not (until now), and they've only been compiling
successfully thanks to a "using namespace mozilla" that this file was picking
up from another .cpp file, via unified builds.
MozReview-Commit-ID: ImRBpAVA0en
--HG--
extra : rebase_source : 291e2777187ef9af17e17eecc5e48eb27dd111ec
`generateUUID()` returns an `nsID`, which is not exactly the same as a
UUID. `nsID`s can be converted to strings using `toString()`, but if
you use `JSON.stringify()`, they become `{}`. Object comparison in JS
performs identity comparison, which would be useless even if the UUIDs
were sensible, which they aren't. As a result, trying to sync keyrings
always failed, because it always seemed like UUIDs had changed, even
when they hadn't.
Because it never occurred to me that UUIDs wouldn't be strings, I
never even wrote a test for this. Correct this, and fix the test.
Thanks to :vasilica_mihasca and :markh for reporting and diagnosing this.
MozReview-Commit-ID: EthxkFFwRbQ
--HG--
extra : rebase_source : 7b2a258d85bf8aab2bf9895e3a8cac9d34ab8435
When the user switches back to a tab which has the selection highlight on
the document, call UpdateCarets() to bring the carets back.
MozReview-Commit-ID: LxNoNRl4FHZ
--HG--
extra : rebase_source : f6fdc9b5c646b064bbe1e27456bbeaac063bd04c
