844658 - Story - text field context menus

Status: RESOLVED FIXED

(Tracking Graveyard :: Metro Operations, defect, P2)

Description

[Asa Dotzler [:asa]]

For <textarea> and <input type="text"> (and any other text boxes we make) the context menu should look like this: 

- Cut
- Copy
- Paste

If there is no text in the clipboard that can be pasted into text that the user can edit, the default context menu should be:

- Cut
- Copy

Comment 1

[Brian R. Bondy [:bbondy]]

Suggest to make bug 844658 a p=2
Suggest to move bug 845122 into a new bug p=20

Comment 2

[Brian R. Bondy [:bbondy]]

Ignore this I'm going to move bug 845122 into Bug 831909

Comment 3

[Rodrigo Silveira [:rsilveira] [:rodms]]

Removed dependency on bug 845122 since it's now part of bug 831909

Comment 4

[Asa Dotzler [:asa]]

Is this story finished? It appears to be working as expected. Can we resolve it?

Comment 5

[Brian R. Bondy [:bbondy]]

Looks like this is working but there are 2 extra menu items that you don't mention in Comment 0:
1) Select
2) Select All

I'm not sure what Select does, it seems to do nothing, things are already selected. I think that should be removed.  Select All makes sense.

I'd recommend keeping Select All and scrapping Select.
Please let me know what you'd like to do and I'll post a bug.

Comment 6

[Asa Dotzler [:asa]]

Yep. You are correct. There are extra items here. Can you remove them? Select All might be nice, but it's not updating the selection handles. If that's not an absolutely trivial fix, I'd rather we simply remove it.

Comment 7

[Brian R. Bondy [:bbondy]]

Yup I'll do it this iteration so we can close this out.  I created a bug for it so I don't forget (working on another one at the moment).

Comment 8

[Jim Mathies [:jimm]]

I don't think we should remove 'select all', it's a useful command to have in text inputs, particularly those that have overflow.

If there are problems with the markers, then we should fix the markers, not remove useful commands.

'select' simply selects the underlying word. With caret selection it has become obsolete and can be removed.

Comment 9

[Asa Dotzler [:asa]]

If you already have a selection, I don't think you expect or need to change that selection when raising the context menu on that selected text. Let's re-visit context menu content in v2 of we need to but now is not the time to create more work if we can possibly avoid it.

Comment 10

[Jim Mathies [:jimm]]

(In reply to Asa Dotzler [:asa] from comment #9)
> If you already have a selection, I don't think you expect or need to change
> that selection when raising the context menu on that selected text. Let's
> re-visit context menu content in v2 of we need to but now is not the time to
> create more work if we can possibly avoid it.

So yes I think if there's selection already, the two additive selection entries should be removed. But I don't think we should get rid of Select All on a text area that has no selection.

Also, I don't see any issues with the monocle position in this case either, although I have all of the skb patches applied in my test browser.

Comment 11

[Jim Mathies [:jimm]]

Actually even if there's already some selection, Select All should remain as well. Otherwise the user would have to tap to clear, then press-hold and select-all.

Comment 12

[Brian R. Bondy [:bbondy]]

Yup I'll only remove them when there is selection

Comment 13

[Virgil Dicu [:virgil] [QA]]

Mozilla/5.0 (Windows NT 6.2; rv:23.0) Gecko/20130414 Firefox/23.0

Filed bug 861891 for grippers displayed when selecting a word from the context menu.

Things are slightly different from the expected results in comment 0. Can anyone confirm if this is ok?

If there is no text in the clipboard and text box empty: the app bar is displayed when using right click in a text input box. 

If text is available in the clipboard and input box empty: only one option is available: "Paste"

If text is available in the clipboard and text entered: three options displayed: paste, select, select all.

If a word is selected: Cut, Copy, Paste displayed as options for that specific word.

All options are functional.

Comment 14

[Marco Mucci [:MarcoM]]

Hi Asa, please see Virgil's question in Comment #13 regarding the correct behaviour of the feature.

Comment 15

[Asa Dotzler [:asa]]

This sounds OK to me but I'd like Yuan to weigh in on this one part:

"If there is no text in the clipboard and text box empty: the app bar is displayed when using right click in a text input box. "

That one feels a bit odd but it may also be correct. Yuan, what do you think? Do nothing in this case?

Comment 16

[Yuan Wang(:Yuan) – Mobile Firefox Design Lead]

Thanks for catching those. 

1. "If there is no text in the clipboard and text box empty: the app bar is displayed when using right click in a text input box. "

I agree. In this case, Right-click in text field should not trigger app bar. It should do nothing. 

2."If text is available in the clipboard and input box empty: only one option is available: "Paste"
I think this is the right behavior. 
But I noticed when touch is in use, long-tap to bring up "Paste" dismisses the soft keyboard. As long as the focus is in a text editor, we should just keep soft keyboard open.

3. If text is available in the clipboard and text entered: three options displayed: paste, select, select all.
I think we should change the order to "Select, Select All, Paste". In this case, Paste may not be the function that is mostly used. 

4. If a word is selected: Cut, Copy, Paste displayed as options for that specific word.
This sounds right to me. 

If that makes sense to everybody, I can file the change bugs.

(In reply to Virgil Dicu [:virgil] [QA] from comment #13)
> Mozilla/5.0 (Windows NT 6.2; rv:23.0) Gecko/20130414 Firefox/23.0
> 
> Filed bug 861891 for grippers displayed when selecting a word from the
> context menu.
> 
> Things are slightly different from the expected results in comment 0. Can
> anyone confirm if this is ok?
> 
> If there is no text in the clipboard and text box empty: the app bar is
> displayed when using right click in a text input box. 


> 
> If text is available in the clipboard and input box empty: only one option
> is available: "Paste"
> 
> If text is available in the clipboard and text entered: three options
> displayed: paste, select, select all.
> 
> If a word is selected: Cut, Copy, Paste displayed as options for that
> specific word.
> 
> All options are functional.

Comment 17

[Tim Abraldes [:TimAbraldes] [:tabraldes]]

Verified for it7.

Filed bug 876017.
Reproduced bug 861891, though I think that behavior is desirable.
Reproduced bug 869175.

Comment 18

[Samvedana (:Samvedana)]

User Agent: Mozilla/5.0 (Windows NT 6.2; Win64; x64; rv:25.0) Gecko/20130707 Firefox/25.0
Build ID: 20130707031138

WFM for iteration-9
Tested on Windows 8.1 preview using latest nightly build from ftp://ftp.mozilla.org/pub/firefox/nightly/2013/07/2013-07-07-03-11-38-mozilla-central/


STR and expected results:
1.Open Firefox Metro.
2.Open any wiki page and copy any word.
3.Try to paste it in search bar.Use right click and paste option.
4.Now, again right click on search bar after text. You should see "Select", "Select All" and "Paste" options.

Actual result:
I am getting expected result.

Comment 19

[Samvedana (:Samvedana)]

User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0
Build ID: 20130825030201
Built from http://hg.mozilla.org/mozilla-central/rev/01576441bdc6

WFM
Tested on windows 8 using latest nightly for iteration-12. Followed steps provided in comment18 and got expected result.