Users should have a clear sense of when they are browsing in a Private tab vs when they are browsing in a normal one. We should change the colour of the UI to reflect this. Touchpoints: * Title bar * Awesomescreen * Menu? * Context menus / doorhangers? In addition, if a user has a Persona theme installed, it should be disabled here to help communicate that they are in Private browsing mode A mockup is attached of a darkened title bar and awesomescreen. *This is not the final visual design*, but we should start thinking about how to implement this while we finalize the look.

I think(?) we're keeping a purple indicator of some sort for Per Window PB on desktop, perhaps that would make sense in this situation. Also, perhaps the orange highlight around the selected address bar could be purple (this fitting with the theme of replacing orange with purple, a la desktop). Just some thoughts.

To support a new state, we have to create a custom view. Since we want it to be generic, and basic extensions of Android views, this patch adds a "common piece of code" as a "GeckoView.java.frag", which is converted into required custom views during compile time. (The classes are specified in the Makefile). Also, to shorten the view names, a new approach of using "Gecko.CustomView" is used in XML, instead of the lengthy "org.mozilla.gecko.CustomView". This is currently added only for the views added by the above mentioned GeckoView.java.frag. This will be extended to other custom views in the nearest future. Since Gecko.CustomView cannot be translated to a class, it has to be specified in GeckoViewsFactory.java for the Android to know. A new attribute is added in attrs.xml, which will be used in subsequent patches to specify the private browsing state. GeckoView.java.frag: A state variable is stored to know if the view is in private mode or not. When (and only when) the value changes, the value is updated, and the Android is informed to refresh the drawing state. This will inturn create a new drawing state based on the StateListDrawable that the view supports (specified through XML in later patches).

This patch adds the private browsing mode to BrowserToolbar. A new state is added to both XML, and onLightweightThemeChanged(). This will take care of private browsing mode being black even when "personas" are enabled.

This adds the private browsing mode support for AwesomeBar.

This adds the support for TabsButton. All new arrows, text colors, background textures.

This adds the support for menu button. New purple menu button for phones and tablets.

Private tabs support for awesomescreen.

Background for AwesomeBar tabs. The target given to awesomebar is used by the tabs to know the state of the tab (new or current).

Comment on attachment 682325 [details] [diff] [review] Part 1: Shadowed android views >diff --git a/mobile/android/base/GeckoView.java.frag b/mobile/android/base/GeckoView.java.frag >+public class Gecko@APPVIEW@ extends @APPVIEW@ { APPVIEW -> VIEW >+ private static final int[] STATE_PRIVATE_MODE = { R.attr.state_private_mode }; state_private_mode -> state_private (to match the Android state_* attributes) >diff --git a/mobile/android/base/Makefile.in b/mobile/android/base/Makefile.in >+# Replace @APPVIEW@ with different View names. >+$(FENNEC_PP_JAVA_VIEW_FILES): GeckoView.java.frag >+ @rm -f $@ >+ cat $< | sed s,@APPVIEW@,$(patsubst Gecko%.java,%,$@),g >> $@ ; \ APPVIEW -> VIEW >diff --git a/mobile/android/base/resources/values/attrs.xml b/mobile/android/base/resources/values/attrs.xml >+ <declare-styleable name="PrivateBrowsing"> >+ <attr name="state_private_mode" format="boolean"/> state_private_mode -> state_private (to match the Android state_* attributes) r+ with those nits fixed

Comment on attachment 682375 [details] [diff] [review] Part 6: AwesomeScreen >diff --git a/mobile/android/base/CustomEditText.java b/mobile/android/base/CustomEditText.java >+ public void setPrivateMode(boolean isPrivate) { >+ // android:textColorHighlight cannot support a ColorStateList. >+ setHighlightColor(isPrivate ? 0xFFD06BFF : 0xFFFF9500); We might want to use CONSTs or colors.xml values for this, instead of hard coding them. (True for any other hardoced colors I missed too) r+ with nits fixed

https://hg.mozilla.org/integration/mozilla-inbound/rev/cdf30a34dec9 https://hg.mozilla.org/integration/mozilla-inbound/rev/d5f4626f5b73 https://hg.mozilla.org/integration/mozilla-inbound/rev/e0a0a5b98b95 https://hg.mozilla.org/integration/mozilla-inbound/rev/944db176184e https://hg.mozilla.org/integration/mozilla-inbound/rev/984a10bc4125 https://hg.mozilla.org/integration/mozilla-inbound/rev/585a7f8fc448 https://hg.mozilla.org/integration/mozilla-inbound/rev/abfc930bc7cd (This definitely needs clobbering)

What were the color gradients used here? Maybe we can hijack them for the desktop as well? :-)

Orange is #FF9500 and Purple is #D06BFF

Hrm, I was mostly asking about the black gradients in https://bugzilla.mozilla.org/attachment.cgi?id=676594. (I haven't actually seen a real build with these changes yet!)

https://hg.mozilla.org/integration/mozilla-inbound/rev/bf8f4b151716 <-- this was missing.

https://hg.mozilla.org/integration/mozilla-inbound/rev/cd7c2afe0cb8 <-- sorry about that.

Backed out for failures https://hg.mozilla.org/integration/mozilla-inbound/rev/72b699c67ed1 https://hg.mozilla.org/integration/mozilla-inbound/rev/6cb490697a27 https://hg.mozilla.org/integration/mozilla-inbound/rev/a58070f72659

Pushed with proper null checks in AwesomeBar and AwesomeBarTabs: https://hg.mozilla.org/integration/mozilla-inbound/rev/61680b40ff9d https://hg.mozilla.org/integration/mozilla-inbound/rev/7aca474f43cb https://hg.mozilla.org/integration/mozilla-inbound/rev/ed08b110d4cc https://hg.mozilla.org/integration/mozilla-inbound/rev/30ae7de73333 https://hg.mozilla.org/integration/mozilla-inbound/rev/dd259d461971 https://hg.mozilla.org/integration/mozilla-inbound/rev/ff583cde143c https://hg.mozilla.org/integration/mozilla-inbound/rev/90213ba41937 All green: https://tbpl.mozilla.org/?tree=Try&rev=74d39b8a30af

https://hg.mozilla.org/mozilla-central/rev/61680b40ff9d https://hg.mozilla.org/mozilla-central/rev/7aca474f43cb https://hg.mozilla.org/mozilla-central/rev/ed08b110d4cc https://hg.mozilla.org/mozilla-central/rev/30ae7de73333 https://hg.mozilla.org/mozilla-central/rev/dd259d461971 https://hg.mozilla.org/mozilla-central/rev/ff583cde143c https://hg.mozilla.org/mozilla-central/rev/90213ba41937

The toolbar buttons in tablet UI (i.e. small tablet, Nexus 7) are not themed. Is there a bug for that?

(In reply to Thomas Stache from comment #20) > The toolbar buttons in tablet UI (i.e. small tablet, Nexus 7) are not > themed. Is there a bug for that? That is bug 817138

The new PBM theme has landed on the latest Nightly build. Closing bug as verified fixed on: Firefox 20.0a1 (2012-12-03) Device: Galaxy S2 OS: Android 4.0.3

A bare bones file to support light/dark themes in subsequent patches (that are aurora approved already). This doesn't have any trace of private browsing.

Comment on attachment 696798 [details] [diff] [review] Patch: For Aurora [Approval Request Comment] Bug caused by (feature/regressing bug #): New feature. User impact if declined: This patch is needed by other persona related patched dealing with light/dark themes. Testing completed (on m-c, etc.): Landed in m-c long long ago. Risk to taking this patch (and alternatives if risky): Very low. String or UUID changes made by this patch: None. This is a bare-bones patch. Bits-n-bytes related to light/dark theme will be added later to this file.

Comment on attachment 696798 [details] [diff] [review] Patch: For Aurora Is this the right patch?

Yes it is. GeckoView.java.frag is empty -- without private browsing.

Comment on attachment 696798 [details] [diff] [review] Patch: For Aurora Low risk , well tested ,( ~ a month) patch needed for persona's (targeting FF19). Approving on aurora.

That one little patch for Aurora: https://hg.mozilla.org/releases/mozilla-aurora/rev/174fdb04facf