468221 - When right clicking an unselected url in the url bar, the copy function is grayed out.

Status: RESOLVED FIXED

(Core :: Widget: Cocoa, defect)

Description

[Luke]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4

When browsing, I often want to copy the current url.  If it is unselected I right click it, only to have the copy option grayed out.  The copy command should be selectable.

Reproducible: Always

Steps to Reproduce:
1.Have the url for the current page unselected.
2.Right click on the url.
3.The copy command is grayed out.


Expected Results:  
The copy command should be selectable.

Comment 1

[Simon Bünzli]

WORKSFORME: Right-click -> Copy Link Location

Comment 2

[Stefan [:stefanh]]

Do you mean that you want to be able to copy the url form the location bar even if it's not selected? I'm not convinced that would be a good idea.

Comment 3

[Luke]

When the url is unselected I can still right click it and have a context menu pop up.  It includes the option for paste, which when selected will paste whatever is on my clipboard to the url location bar.  The option for copy is there, but this is grayed out and I can't select.  I merely wish for this function to work as well.

Comment 4

[Dão Gottwald [::dao]]

Did you set browser.urlbar.clickSelectsAll to false?

Comment 5

[Steven Michaud [:smichaud] (Retired)]

I see this too.

I'm not sure we can or should fix it.  But if we do, it will probably
be in Cocoa widgets code.

Comment 6

[Luke]

Browser.urlbar.clickSelectsAll is currently set to true.

Comment 7

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

If there's no selection, why should Copy be enabled?  I know of nowhere else in Mac OS X where Copy is enabled when invoking the context menu on "something" without a selection.

Comment 8

[Stefan [:stefanh]]

It doesn't make sense enabling copy without anything selected... Isn't the whole point that if you don't select anything, you don't want copy the url/text?

Comment 9

[Luke]

It seems like there are two ways of handling this problem.

Include copy as an option:
The menu already is set up to allow an easy and efficient way to paste a url.  While it may not be standard, a copy function in this manner would be extremely easy to use.  For text field in Safari, such as Google.com search, this manner is used.

Use based selection:
The actual standard I can see from OS X for some applications, such as Spotlight, is different from what is currently set up.
     If a non selected text field is right clicked, a cursor appears at the 
     end of the contained string, and an option to paste is present.

This seems to be a case of which side we choose to use, as there are several ways to go about it.

Comment 10

[Samuel Sidler (old account; do not CC)]

When on a page, the user must explicitly make a selection. i.e., simply right clicking on the page with no selection should not enable the "Copy" link. That's not a regression or an unexpected behavior on Mac OS X.

If the user is in an editable region (text box, textarea, etc), your "use based selection" will happen. Full URLs are not selected in this case because that's not how text selection in Mac OS X works. You can try this in Firefox now using the textarea to make a comment.

This bug should be WONTFIX or INVALID and likely shouldn't have been confirmed since it's not at all a bug.

Comment 11

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #9)
>      If a non selected text field is right clicked, a cursor appears at the 
>      end of the contained string

(In reply to comment #10)
> You can try this in Firefox now using the textarea to make a comment.

FYI, bug 365183 is filed on the fact this doesn't work in Gecko (Sam must have been remembering the fix we hacked into Camino instead), but everything else Sam said is correct.

Comment 12

[Luke]

This

Comment 13

[Luke]

This might have been an error in my writing.  This copy function was only for the url bar.  That is, if an address in the address bar was unselected, right clicking would select it.  The copy function for the link would be grayed out, but the paste function would remain.  This has only to do with the address bar, and not any other field in firefox.

Comment 14

[Sid]

I am seeing a regression of this issue in FF Nightly 38.0a1 in Ubuntu 14.10. Cannot confirm when this issue actually regressed. Details below:

Steps to reproduce:
1. Set browser.urlbar.clickSelectsAll to True.
2. Right click on address bar.

Result:
1. URL is automatically selected.
2. Cut and Copy options in the context menu are disabled. Paste and Select All are activated.
3. If I right click in the address bar again (immediately, with the URL selected), the Cut and Copy options also become enabled.

Expected result:
1. The Cut and Copy options should be enabled after first right click.

What I feel is that the address bar right click event is triggering the Select All action due to the browser.urlbar.clickSelectsAll being set to true. However, the event does not trigger the action to activate the Cut and Copy options (as required) in the context menu. The second time when I right click the address bar (with the address selected in the prior step), the click event triggers the context menu that realises that the address is selected and hence activates the Cut and Copy options as well. What probably needs to be done is that after the Select All action triggers, it should move the control to the code piece managing the options that need to be activated in the context menu. It is instead simply running the context menu's show function so the menu behaves as though the URL is not selected

Comment 15

[Sid]

Attachment: Screengrab of issue - 20150123

Comment 16

[Liz Henry (:lizzard Please n-i to RyanVM, jcristau, or pascal)]

I'm also seeing this on Nightly, MacOSX, buildid 20150123030203. I am opening a new issue in bug 1125203.  This seems to be a problem across platforms, not a cocoa-specific one, and closing this bug again.