As a user, I want a quick and easy way to copy or paste into the nav bar, so I can perform my tasks quicker.
In Fennec, long pressing on the nav bar brings up a context menu with following options (Paste & Go, Paste, Copy address, Add page shortcut). UX will investigate and design how to bring this feature to Fenix.
-I can quickly choose to copy the URL by long pressing on the URL bar
-I can quickly choose to paste a URL into the nav bar
-Long pressing on the URL bar will not automatically copy the URL or paste anything into the nav bar.
This is an experiment we'd like to run, but UX work should be timeboxed to ____, and then make a decision whether to continue.
Talked about this issue - it's a Should, so if it's not too much work it'll be a nice benefit and UX should pick it up and timebox, but should be skipped if we're behind on UX work.
some feedback of mine, that you can take into consideration:
I want "tap+hold -> copy to clipboard" back, atleast as an option, it was amazing! <3
it's way faster (one click instead of two)
I get that this can override users' clipboards, so it's good you're searching for an alternative.
my keyboard swiftkey has a clipboard history. therefore I can't accidentally loose my clipboard's content.
paste and paste & go can be placed in the menu that appears if you click the addressbar once. (only paste & go currently and it's named only paste, I think; atleast in german)
if you ever add an option "add to home screen", then it doesn't need to be on tap&hold imo. there are more intuitive places for it.
one example: the menu that appears when you click the lock/globe icon in the addressbar
I'd suggest to show a standard context menu with: Cut, Copy, Paste and Share
We wouldn't support "Paste & Go" and "Add page shortcut" in this iteration. @vesta0 thoughts?
@topotropic I am good with your suggestion but is there a reason why we don't want to support "Paste & Go" ?
@topotropic What would Cut do here? We're on the browser screen at this point. Would it first open the search page and then cut the entire URL to the copy buffer? It doesn't seem to make sense to Cut unless the user is on a screen where the URL is editable.
Likewise, Paste would seem to require changing to the search screen if it doesn't mean Paste & Go.
My feedback will echo that of @Djfe — the moment I installed Preview and realized it did the automatic copy on longpress I was startled a bit (I was used to a context menu popping up) but I almost instantly fell in love with the simplicity and usefullness of it. During my day-to-day workflow I want copy URLs _way_ more often than I want to paste-and-go to an URL. I understand this might not match _everyone_'s experience on the planet, but if I could choose I'd keep this in the settings as an option ( _"Enable quick URL copy"_ or something along those lines).
As for exposing "Paste & Go" I'd think exposing it as a contextual option after tapping into the URL bar would be a similarly workable solution (some other browsers show a "go to _[url]_ on clipboard" option underneath the URL editor bar, on top of the suggestions).
@colintheshots yeah, that makes sense, I kind of saw it as shortcut to the context menu that appears on the search screen. I'll look into it.
@vesta0 can you point me to the feedback we got about long press to copy? thanks!
@vesta0 I'd suggest to have "Copy" and "Paste & Go" assuming that people go to search view when they just want to paste, cut or edit an URL
@topotropic I like your suggestion but I think we may also want to include just "Paste" to give users the option of modifying a URL or search term. What do you think?
Also here's the relevant UR feedback and the UX decision regarding removing the auto-copy feature.
I don't have a strong opinion here, my main concern about "Paste" is that we go to the search screen and the search box jumps to top and keyboard pops out.
But let's add it, people might wonder how to get to "Paste" when "Paste & go" is in the menu. I'll update the root issue above with the spec.
Sounds good @topotropic thank you!
@topotropic will add designs before Sprint Planning on Friday, and then we will add it in.
See UX Specs section above, describing interaction, no mock needed.
I want to confirm this is the expected menu popup style:
@topotropic
This is what Fennec looks like:
I want to confirm this is the expected menu popup style
I suggest to use the same border radius as for the other menus.
@topotropic, @cadeyrn I now have it with rounded corners:
@sblatz we should use the same context menu we use when long pressing text or long pressing on URL field on search screen – sorry for not being more explicit right from the beginning.
We could use this to start creating UI components; could be "Context menu" and
have the following variables (completely made up the variable names --> with the dimensions, we would need to think it through a little more so that they are broad enough to cover for more cases but still be descriptive)
type.xml
dimens.xml
also the current elevation for the context menu should be 8dp or so
@topotropic
This seems to be against the material design standards for contextual menus and will require us to make a custom menu style. This type of menu is usually found only when a textfield is editable (and then this menu is displayed with "copy" and "paste" by default). Our browser toolbar is not editable when browsing, though, and thus would require us to do a lot of custom work here.
Chrome handles this by sending you to edit mode when pressing and holding:
Fennec simply inflates a vertical menu like I've shown above in my previous comment.
After a conversation with @topotropic I'm going to timebox working on this newer UI to ~1 hour to see how hard it is to do custom.
Updated to have this custom view:
Hi
Not sure it is the right place to ask but in addition to "Copy" , could there also be a "Copy & Go Private" if we are in normal mode, or "Copy & Go Not Private" if we are in private mode.
This would open the same URL in the other mode, which I often do.
EDIT: just opened feature request #5170
@klint what would happen to your tab's history then?
Should it be deleted? or kept? or moved to private/non-private?
it's a cool idea but the behavior needs to be consistent.
@Djfe: I'm continuing the discussion in feature request #5170 if you don't mind :)
Verified as fixed on build 2.0.0-rc2.
Paste and paste & go seem to be unavailable unless the clipboard contains a Valid URL
Paste options should be available as long as the clipboard has is not empty.
If it is not a valid url, it should perform a search.
@topotropic Can you verify if the behavior described in @nahuhh's comment is UX's expectation?
Currently "paste" and "paste & go" only display if the clipboard has a URL copied to it. Do you want it to work with search terms as well?
Yes, that makes sense. Thanks!
Most helpful comment
some feedback of mine, that you can take into consideration:
I want "tap+hold -> copy to clipboard" back, atleast as an option, it was amazing! <3
it's way faster (one click instead of two)
I get that this can override users' clipboards, so it's good you're searching for an alternative.
my keyboard swiftkey has a clipboard history. therefore I can't accidentally loose my clipboard's content.
paste and paste & go can be placed in the menu that appears if you click the addressbar once. (only paste & go currently and it's named only paste, I think; atleast in german)
if you ever add an option "add to home screen", then it doesn't need to be on tap&hold imo. there are more intuitive places for it.
one example: the menu that appears when you click the lock/globe icon in the addressbar