917514 - Edit mode not left when returning to content

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Richard Newman [:rnewman]]

* Open about:home.
* Tap the URL field. Observe that the menu and tab switcher disappear.
* Tap back into the content area (e.g., to scroll).
* Observe that edit mode is still quietly active, and you have to hit Back to get the menu button to show.

Have tested 26 and 25.

Comment 1

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Some discussion about this issue has previously occurred in bug 902039, which was marked invalid.

As per the discussion there, one thing that makes fixing this difficult is the distinction between entering the awesomescreen on a new tab (about:home) and entering the awesomescreen by changing the current tab's url.

Comment 2

[Brian Nicholson (:bnicholson)]

This has thrown me off too; I can take a look.

Comment 3

[Brian Nicholson (:bnicholson)]

Unassigning myself after looking through the comments in bug 902039. This will need some UX direction before proceeding.

Comment 4

[Lucas Rocha (:lucasr)]

Ian, any input here?

Comment 5

[Ian Barlow (:ibarlow)]

What Richard is describing is basically the interaction flow I've always wanted when you tap the URL bar, but we haven't ever seemed to get working right, for various reasons. 

Take a look at this flow, and we can discuss the details in this bug. http://cl.ly/image/3w3d1D103R3j

Comment 6

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

I feel like this new design hits some of the same issues we had before.

For example, in the bottom-middle image, what happens when you hit the tab tray button? Do we show about:home or the tab you're actually on?

One unrelated suggestion (via a discussion with :wesj) is to have the about:home page and the pseudo-about:home-replace-the-current tab page have a obviously different appearances so they can have different interaction paradigms. For example, the latter can be an overlay whereas about:home will continue to be an about:home page.

Comment 7

[Ian Barlow (:ibarlow)]

(In reply to Michael Comella (:mcomella) from comment #6)
> I feel like this new design hits some of the same issues we had before.
> 
> For example, in the bottom-middle image, what happens when you hit the tab
> tray button? Do we show about:home or the tab you're actually on?

In this case we would show about:home as the tab, since that it what is currently in view.

> One unrelated suggestion (via a discussion with :wesj) is to have the
> about:home page and the pseudo-about:home-replace-the-current tab page have
> a obviously different appearances so they can have different interaction
> paradigms. For example, the latter can be an overlay whereas about:home will
> continue to be an about:home page.

That pretty much goes against everything we did in the redesign, where the intent was to merge the two experiences since they are both intended to do the same thing: provide quick access to your stuff. 

If we fix this bug -- which I would like to, as I'm still not crazy about the current interaction of leaving the url bar stretched open -- I'd like to try what I've mocked up in these flows before anything else. It seems like fairly minor changes to what we have already:

1. When the URL bar is focused, tapping back returns the title bar to its normal state
2. After tapping back, the title bar has the default "Enter search or address" text. If you tap the URL bar again right now, the highlighted URL of the previous page you were on is displayed in the field.

Comment 8

[Lucas Rocha (:lucasr)]

Ian, is that something you'd like to get fixed for 26?

Comment 10

[Ian Barlow (:ibarlow)]

Only if it's possible. It's such a slim case to solve for -- 99% of people just will tap the url bar, type a search or url and go to a page. Backing out halfway through is not a very common a case. 

If we can fix it, great, if not, we can follow it up in the next release.

Comment 11

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

(In reply to Ian Barlow (:ibarlow) from comment #7)
> (In reply to Michael Comella (:mcomella) from comment #6)
> > I feel like this new design hits some of the same issues we had before.
> > 
> > For example, in the bottom-middle image, what happens when you hit the tab
> > tray button? Do we show about:home or the tab you're actually on?
> 
> In this case we would show about:home as the tab, since that it what is
> currently in view.

From this state, if you select a different tab in this tabs tray and re-open the tabs tray, I presume the previous tab you were on no longer appears as about:home?

Comment 12

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Anything actionable here? Has bug 965548 and subsequent bugs fixed the issues here?

Comment 13

[Richard Newman [:rnewman]]

(In reply to Michael Comella (:mcomella) from comment #12)
> Anything actionable here? Has bug 965548 and subsequent bugs fixed the
> issues here?

There might be. The introduction of the Big Fat Editing "X" helped by providing a visual cue for editing mode, but some of the obstacles in this bug still exist.

The new/current experience is this:

* Tap URL bar. Menu and tab switcher disappear, keyboard appears.
* Either: hit back (!!!!), or touch the content.
* Keyboard disappears, text still shows in full-width field, big "X" next to it.
* Either: hit back, or tap the X, and we're back to the start.


So: the surprising part of this is that you can tap once, tap back, and *not end up where you where*. The first back hit, or touching the content, dismisses the keyboard but doesn't leave edit mode.

(My phone has a hardware back button, so it doesn't show the keyboard-dismiss "V".)

You have to tap back twice, or touch the content and then hit back, to 'undo' a simple tap of the text area.


Potential solutions:

* If the user didn't modify the text, leave edit mode when they dismiss the keyboard.

* Have two variants of edit mode: one being full-width-with-X, one being identical to the non-edit view of the URL bar. When you hide the keyboard, you're functionally able to dive straight into the menu or the tab switcher, even if you're technically still editing the URL.

These might only make sense for software keyboards; I'm not sure what we do now for hardware keyboards. The core concept is to only accommodate text entry (via width change) when the user is actually entering text.

As always, Ian's input is welcome.

Comment 14

[Ian Barlow (:ibarlow)]

Are we discussing this because it's an actual problem? Or just because this bug is still open? 

As I see it, edit mode now behaves precisely as intended -- that is, we now have an easy way of dismissing it in a single tap and returning users to their previous page (with the X), while also maintaining the ability which many desire to be able to tap back once to hide the keyboard but not fully exit edit mode.

I'm inclined to resolve this worksforme, unless anyone objects.

Comment 15

[Richard Newman [:rnewman]]

Good enough for me!

Comment 16

[Cristina Madaras, QA [:CristinaM]]

Based on Ian's comment 14 I will mark this bug as verified fixed.