Closed Bug 1045655 Opened 6 years ago Closed 6 years ago

Focus search bar and open keyboard on launch


(Firefox for Android Graveyard :: Search Activity, defect, P1)

33 Branch


(firefox35 verified)

Firefox 34
Tracking Status
firefox35 --- verified


(Reporter: ibarlow, Assigned: Margaret)




(3 files, 1 obsolete file)

We've heard feedback that after launching the search activity, having to tap the title bar to start searching feels like an extra step. Particularly on tablets where you have further to reach. 

Our initial thinking here was that search history, as well as "other stuff we put on the search homepage" would be useful enough to not require a keyboard input right away. That may still be the case when we add more things. 

But for now, I would suggest we focus on speed, and making new searches as easy as possible. In other words, let's fire up the keyboard right away instead of making users tap again.
Assignee: nobody → margaret.leibovic
Priority: -- → P1
Duplicate of this bug: 1052015
I'd like to see if we could do something like this since the keyboard does end up covering the visuals we've decided to leverage for showing the search engine that's being used and the 3-dot overflow menu.

However, those would not be shown once typing has started.
One problem I'm finding here, and with the current search history UI, is that if we launch the activity with the keyboard open, if the user tries to tap on one of the search history terms we show, it will require two clicks (once to dismiss editing mode and once to select a search term).

I suppose a quick fix for this could just be to make that click select the suggestion, rather than dismissing the keyboard, but then we wouldn't have the same "click outside to deactivate" functionality.
Yeah, I had my concerns around that as well... But I see this as more of a suggestion for this first iteration since it's really focused on speed and new searches while we start building a richer story and UX around history item (like the cards UI).
I talked with antlam a bit about the click capturing issue I described in comment 3, and we decided to just get rid of that click-capturing behavior. If the user just wants to dismiss the keyboard without affecting anything else that's visible, they can always do that with the back button.

However, if the user clicks on the webview content, the EditText will lose focus, so we need to make sure we appropriately exit editing mode. To accomplish this I added a focus change listener. While it is true this listener will fire when we manually set the search bar to active/inactive, setEditState will just bail early in that case.
Attachment #8471215 - Flags: review?(eric.edens)
Comment on attachment 8471215 [details] [diff] [review]
Focus search bar and open keyboard on launch

Review of attachment 8471215 [details] [diff] [review]:

::: mobile/android/search/java/org/mozilla/search/autocomplete/
@@ +79,5 @@
> +        editText.setOnFocusChangeListener(new View.OnFocusChangeListener() {
> +            @Override
> +            public void onFocusChange(View v, boolean hasFocus) {
> +                listener.onFocusChange(hasFocus);

I just realized I should put a null check around this.
Attachment #8471215 - Flags: review?(eric.edens)

I have two suggestions to move forward:

1) Wrangle the bug's scope -- the only changes should involve showing the keyboard at launch.
2) If that's not technically possible, and we have to start tweaking more stuff, add some rigorous UX documentation so that we can verify transitions and states.


Changing the tap-backdrop-to-dismiss approach introduced some bumps in the UX. A couple of examples:

- When viewing the webview, if you start typing and then dismiss the keyboard, the suggestions are still visible (screenshot).
- The input bar maintains focus after hiding the keyboard; hitting the back button clears focus; hitting the back button a second time takes you to the home screen.
- The search bar can be focused when the keyboard is down. Is this intended?
- When suggestions are shown and the keyboard is down, tapping on the webview dismisses the suggestions, but flinging does not.

I think this is symptomatic of scope creep. The original bug (show the keyboard!) has grown to include fundamental changes to our click handling.

If we go with approach (2) from above, then I'd like to see a UX state diagram. I believe these are the components with their respective states:

Search bar:
  Not focus



Main view:
  History (home screen)
  Blank (suggestions?)
  Web results

Using the above as an example, there would be 24 different states (some being unreachable), with transitions being user events.
(In reply to Eric Edens [:eedens] from comment #7)

> 1) Wrangle the bug's scope -- the only changes should involve showing the
> keyboard at launch.

Fair point, I'll file a follow-up bug for the click capturing issue.
Attachment #8471215 - Attachment is obsolete: true
Attachment #8471706 - Flags: review?(eric.edens)
(In reply to Eric Edens [:eedens] from comment #7)

> - When viewing the webview, if you start typing and then dismiss the
> keyboard, the suggestions are still visible (screenshot).

This is bug 1051983.
Comment on attachment 8471706 [details] [diff] [review]
Focus search bar and open keyboard on launch

Review of attachment 8471706 [details] [diff] [review]:

Looks good to me!
Attachment #8471706 - Flags: review?(eric.edens) → review+
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 34
Verified as fixed in build 35.0a1 (2014-09-08);
Google Nexus 7 (Android 4.4.4);
Samsung Galaxy R (Android 2.3.4).
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.