Closed Bug 943400 Opened 9 years ago Closed 9 years ago

Don't invoke the text-selection action-bar on initial input focus


(Firefox for Android Graveyard :: General, defect)

28 Branch
Not set


(firefox28+ verified, fennec28+)

Firefox 28
Tracking Status
firefox28 + verified
fennec 28+ ---


(Reporter: aaronmt, Assigned: wesj)




(Keywords: reproducible)


(1 file)

Regression from bug 768667. On focus the action-bar is shown on-top of the nav-bar. On key-insert, the action-bar is removed.

Focus an <input/>, see action-bar. We should wait for a selection.
Assignee: nobody → wjohnston
tracking-fennec: ? → 28+
This isn't a regression. We didn't have these before.

I also don't think this should ONLY happen on selection. We need a way to paste even if there is not text in the input (and we have other options like "Add search engine" as well). Android uses a floating "Paste" button that shows up randomly sometimes. I hate it, and I'd hate to copy awful UI design (but I have a feeling we will end up doing it anyway, and then regretting it when Android removes it later).

Part of the problem here is that the cursor disappears when you start typing, which is non-Androidy as well. When the cursor disappears, we stop showing the action mode.

Alternatively, we could try something like only showing if we're focusing an already focused input. But I don't think only showing the bar when something is selected will work.
Keywords: regression
Summary: Regression: Don't invoke the text-selection action-bar on initial input focus → Don't invoke the text-selection action-bar on initial input focus
I talked to lucas about this for a bit. So, IMO, the problem here is that we're showing a selection handle whenever a textbox is focused. Java (currently) uses that (along with the presence of actions that can be performed) as a key to say "Show an actionbar". Typically, we've been moving away from js driving the java ui, but text-selection is one case where... that's going to be tough. JS has to know a lot about the java ui to tell it what type of handle to show and where.

So in this case, since JS is driving the UI, maybe we just let JS be smart and not show the handle when the textbox is first focused (or if we're really really in love with showing the handle then, we send zero actions with it). Will throw up a test build.
Attached patch PatchSplinter Review
This implements that:

What do you think ian?
Attachment #8338658 - Flags: review?(mark.finkle)
Flags: needinfo?(ibarlow)
This feels pretty good, Wes. I wasn't convinced on using the action bar for the paste command as well (vs that floating menu, which I actually like) but it feels good in practice, so let's go with it. 

I have some overall visual feedback for you re: action mode in general, but I'll file that in a separate bug.
Flags: needinfo?(ibarlow)
Attachment #8338658 - Flags: review?(mark.finkle) → review+
Comment on attachment 8338658 [details] [diff] [review]

>+            // Was the element already focused before it was clicked?
>+            let isFocused = element == BrowserApp.getFocusedInput(BrowserApp.selectedBrowser, true);

Use () around the test:
              let isFocused = (element == BrowserApp.getFocusedInput(BrowserApp.selectedBrowser, true));
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 28
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.