814358 - Address bar : when the user pastes text with the contextual menu, paste the text in the context - hence the name "contextual"

Status: RESOLVED WORKSFORME

(Firefox :: Menus, defect)

Description

[Nicolas Barbulesco]

Hello,

I encounter a bug in Firefox. I right-click in the address bar, I choose to paste. So the text has to get pasted in the address bar. But, in some cases, it gets pasted elsewhere instead.

I encounter this bug in Firefox 3.6.23 Win XP and in Firefox 16.0.2 Linux (Ubuntu).

I have some text in my clipboard.

I have an empty Firefox window. I put this address in the address bar :

http://fr.wikipedia.org/w/index.php?title=Sp%C3%A9cial%3ARecherche&profile=advanced&search=Vivent+les+ours%C2%A0!!!&fulltext=Search&ns0=1&ns9=1&ns11=1&redirs=1&profile=advanced

I press Return, and, immediately, I right-click in the address bar. Firefox connects and loads the page. This takes 2 seconds. But I have my contextual menu as soon as I right-click, 2 seconds before the page gets loaded.

Now, the page is loaded, I still have my contextual menu, and I decide to choose "Paste" in my contextual menu.

Expected behaviour : the clipboard's content gets pasted in the address bar.

Actual behaviour : the clipboard's content gets pasted in the big search field of the Wikipedia page !

This is wrong.

The contextual menu has to act... on the context - hence the name "contextual".

This usability problem is also a security problem. The pasted text can be private, it can be a porn address, it can contain a user name, a password..., it can be confidential. And the user does not intend to give it to the page. And, as soon as the text gets pasted in the page, the page can read it and send it to a server.

Thank you for correcting that bug, and keep up the good work !

Nicolas

Comment 1

[Gabriela [:gaby2300]]

Could you please try with Firefox 17?

Comment 2

[Paul Silaghi, QA [:pauly]]

I can reproduce this on Nightly 2012-11-26, but I'm not convinced this is a bug. Wikipedia seems to automatically move the cursor to the search box. Cannot reproduce on other sites.

Comment 3

[arni2033]

(In reply to Paul Silaghi, QA [:pauly] from comment #2)
> I'm not convinced this is a bug. Wikipedia seems to automatically move the cursor to the search box.
Context menu is always being opened for exact target, and clicking menuitems should always have effect for that target, IF it still exists when user clicks menuitem. Does that sound reasonable?
This is not Location bar bug; you can test it with Location bar, Search bar, Find bar on the following "data:" page. Actually, this example shows that this bug applies to any input on any page:
>   data:text/html,<input autofocus/><script>setTimeout(function(){location.reload()},5000);</script>

STR:   (reproduced on: Win7_64, Nightly 44 (sic!), 32bit, ID 20150930030231, new profile, safe mode)
1. Copy some text to clipboard
2. Open given "data:" url
3. Open findbar on that page
4. Right-click urlbar/findbar/searchbar
5. Wait 6 seconds (until <input> on page gains focus)
6. Click "Paste" menuitem

Result:       Your text from Step 1 was pasted in <input> on the page, not urlbar/searchbar/findbar
Expectations: Menuitem action should apply to the same element user clicked with right mouse button

Comment 4

[Marco Bonardo [:mak]]

context menus should likely be closed when the focused element changes. Could be a platform bug, more than a frontend one.

Comment 5

[arni2033]

(In reply to Marco Bonardo [::mak] from comment #4)
> context menus should likely be closed when the focused element changes.
I forgot to note here that Googlechrome:
1) handles browser fields more carefully: if they have focus, they don't lose it, and their values don't change (the same would solve some firefox location bar issues I saw around, including this one).
2) has the same issue with inputs in page content.
And I believe we [you, the mozilla?] should also treat (and fix) them separately.

Comment 6

[Andrei Purice]

Following the reporter's steps I am able to confirm that the issues doesn't happen anymore on Windows 10x64 on any of the current versions of Firefox Nightly 87.0a1 (2021-02-18), beta 86.0 and release 85.0.2. No crashes occur under the given test case.

Closing this issue as Resolved > Worksforme.
Feel free to re-open or file a new bug if this issue reoccurs again.