Perhaps a dupe to bug 1214939, but definitely higher priority than that one.

The doorhangers are being constructed via code [1], rather than being inflated in xml, so I think they're avoiding the normal process by which Views inherit the application theme. I tried adding the theme to the DoorHanger constructor, but it did work as I would have expected it to – it's possible it's because this is a support library feature, or that the CheckBox needs to be exchanged for an app compat version. [1]: https://mxr.mozilla.org/mozilla-central/source/mobile/android/base/widget/DoorHanger.java?rev=d548ba019a7c#26

(In reply to Michael Comella (:mcomella) from comment #1) > The doorhangers are being constructed via code [1], rather than being > inflated in xml, so I think they're avoiding the normal process by which > Views inherit the application theme. Nevermind – I explicitly added the AppCompatCheckBox to the layout (without other changes) and it was the expected orange tint. It looks like this code is using the wrong layout inflater (I believe the support library injects an inflater). There is a bug open for AppCompat not working in Fragments, the work-around being to use the Activity's layout inflater. The bug was closed but apparently it wasn't a perfect fix – a better fix will be released in v23. Source (follow the link): http://stackoverflow.com/a/29806345

It turns out we never extended AppCompatActivity in GeckoApp (rather, we extended FragmentActivity) so that was the problem. Yay! ...but then I tested on GB and the menu button stops working because of it. Known issue [1]. Go Android! Potential solutions: * Determine if overriding the menu button functionality could solve this (e.g. use the API 11+ menu here). * Add a software menu button (bug 1209967) * Don't extend AppCompatActivity, be afraid of what other problems this could cause (bug 1215079?), and use a solution like explicitly adding AppCompatCheckBox in the problem places. [1]: http://stackoverflow.com/q/32575557

Bug 1220196 - Explicitly set AppCompatCheckBox. r=sebastian We don't extend AppCompatActivity in GeckoApp (bug 1220309) so these edge cases are not getting auto-inflated to their AppCompat counterparts.

Comment on attachment 8681533 [details] MozReview Request: Bug 1220196 - Explicitly set AppCompatCheckBox in xml. r=sebastian Bug 1220196 - Explicitly set AppCompatCheckBox in xml. r=sebastian We don't extend AppCompatActivity in GeckoApp (bug 1220309) so these edge cases are not getting auto-inflated to their AppCompat counterparts.

Comment on attachment 8681533 [details] MozReview Request: Bug 1220196 - Explicitly set AppCompatCheckBox in xml. r=sebastian https://reviewboard.mozilla.org/r/23847/#review21347

https://hg.mozilla.org/integration/fx-team/rev/88814a58c066bd4f2cbda7a719045f21b244f538 Bug 1220196 - Explicitly set AppCompatCheckBox in xml. r=sebastian

removing the b2g 2.5 flag since this commit has been reverted due to an incorrect merge, sorry for the confusion