Closed Bug 844658 Opened 12 years ago Closed 12 years ago

Story - text field context menus

Categories

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

x86
Windows 8.1
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: asa, Assigned: bbondy)

References

Details

(Whiteboard: feature=story c=context_menus u=metro_firefox_user p=1)

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
Priority: -- → P2
Whiteboard: feature=story c=context_menus u=metro_firefox_user → feature=story c=context_menus u=metro_firefox_user p=0
Depends on: 831952
Component: General → Metro Operations
Product: Firefox for Metro → Tracking
Version: Trunk → ---
Depends on: 845122
Whiteboard: feature=story c=context_menus u=metro_firefox_user p=0 → feature=story c=context_menus u=metro_firefox_user p=20
Blocks: metrov1backlog
No longer blocks: metrov1planning
Suggest to make bug 844658 a p=2 Suggest to move bug 845122 into a new bug p=20
Flags: needinfo?(mmucci)
Ignore this I'm going to move bug 845122 into Bug 831909
Flags: needinfo?(mmucci)
Whiteboard: feature=story c=context_menus u=metro_firefox_user p=20 → feature=story c=context_menus u=metro_firefox_user p=2
Assignee: nobody → rsilveira
Removed dependency on bug 845122 since it's now part of bug 831909
No longer depends on: 845122
Assignee: rsilveira → nobody
Is this story finished? It appears to be working as expected. Can we resolve it?
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.
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.
Depends on: 858359
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).
Blocks: metrov1it5
No longer blocks: metrov1backlog
Whiteboard: feature=story c=context_menus u=metro_firefox_user p=2 → feature=story c=context_menus u=metro_firefox_user p=1
Assignee: nobody → netzen
Status: NEW → ASSIGNED
QA Contact: jbecerra
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.
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.
(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.
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.
Yup I'll only remove them when there is selection
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Flags: needinfo?(mozbugs.retornam)
Depends on: 861891
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.
Flags: needinfo?(mozbugs.retornam)
Hi Asa, please see Virgil's question in Comment #13 regarding the correct behaviour of the feature.
Flags: needinfo?(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?
Flags: needinfo?(asa)
Flags: needinfo?(ywang)
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.
Flags: needinfo?(ywang)
Depends on: 869175
Depends on: 869218
Depends on: 869237
No longer depends on: 869218
Verified for it7. Filed bug 876017. Reproduced bug 861891, though I think that behavior is desirable. Reproduced bug 869175.
No longer depends on: 876017
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.
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.
Depends on: 937015
No longer depends on: 861891
OS: Windows 8 Metro → Windows 8.1
Product: Tracking → Tracking Graveyard
You need to log in before you can comment on or make changes to this bug.