Added to Known Issues as:
Unresolved
Users on Android 4.3 will not be able to copy, cut, or paste into the address bar (see 889562)
Please contact release-mgmt@mozilla.com with any questions or corrections.

Comment on attachment 784629[details][diff][review]
Patch
Review of attachment 784629[details][diff][review]:
-----------------------------------------------------------------
::: mobile/android/base/AwesomeBar.java
@@ -92,5 @@
> - // so that it cannot be drawn until hide is called.
> - if (Build.VERSION.SDK_INT >= 11) {
> - getActionBar().hide();
> - }
> -
This was added because, android:visibility of ActionBar and its show()/hide() method doesn't match. We make the visibility "gone" in XML. However, android thinks that the ActionBar is showing when it starts this activity. Hence the Contextual Action Bar (CAB) was not shown. Now that I'm removing action-bar in AwesomeBar, this piece is no longer needed.
@@ -232,5 @@
> }
> }
> });
>
> - mText.setOnLongClickListener(new View.OnLongClickListener() {
We needn't do this. Android shows the CAB by default on any text-view, as it was just a replacement for the long press menu. So this listener is not needed actually.
@@ -238,5 @@
> - public boolean onLongClick(View v) {
> - if (Build.VERSION.SDK_INT >= 11) {
> - CustomEditText text = (CustomEditText) v;
> -
> - if (text.getSelectionStart() == text.getSelectionEnd())
This piece is strange. In 4.3, when you tap on the text view, and then long press, more often, the start and end values are same! :O Android bug!
@@ -241,5 @@
> -
> - if (text.getSelectionStart() == text.getSelectionEnd())
> - return false;
> -
> - getActionBar().show();
No ActionBar anymore.
@@ -253,5 @@
> - mText.setOnSelectionChangedListener(new CustomEditText.OnSelectionChangedListener() {
> - @Override
> - public void onSelectionChanged(int selStart, int selEnd) {
> - if (Build.VERSION.SDK_INT >= 11 && selStart == selEnd) {
> - getActionBar().hide();
Since we don't worry about selection. This isn't needed. Selection handles and selection are taken care of my Android.
@@ -745,5 @@
> updateGoButton(text);
> }
> -
> - if (Build.VERSION.SDK_INT >= 11) {
> - getActionBar().hide();
There is no ActionBar.
::: mobile/android/base/resources/values-v11/styles.xml
@@ -52,5 @@
> - <!-- AwesomeBar ActionBar -->
> - <style name="ActionBar.AwesomeBar">
> - <item name="android:displayOptions">showCustom</item>
> - <item name="android:customNavigationLayout">@layout/awesomebar_actionbar</item>
> - <item name="android:visibility">gone</item>
This doesn't directly reflect the show()/hide() of ActionBar. We load a custom layout and then make it "gone". This wasn't needed actually.
::: mobile/android/base/resources/values-v11/themes.xml
@@ -25,5 @@
> <style name="GeckoAwesomeBarBase" parent="GeckoBase">
> <item name="android:windowBackground">@color/background_normal</item>
> - <item name="android:windowActionBar">true</item>
> - <item name="android:windowNoTitle">false</item>
> - <item name="android:actionBarStyle">@style/ActionBar.AwesomeBar</item>
The idea for this patch came from new about:home. In new about:home, the long press (after a series of hit and miss, as we show a different menu on the url-bar) shows CAB. But the GeckoApp doesn't have an action-bar. It's windowActionBar property is false. If that would work fine, then we actually wouldn't be needing it in old AwesomeBar. And I tried it .. it works :D.
I still don't recollect why I added the ActionBar for AwesomeBar in the first place. May be the honeycomb or ICS might depend on it. I would probably try it tomorrow and update the results. In that case, we can be partial in having the logic for only those devices that have the ActionBar.