Open Bug 814358 Opened 8 years ago Updated 5 years ago

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

Categories

(Firefox :: Menus, defect)

defect
Not set
critical

Tracking

()

People

(Reporter: nicolas.barbulesco, Unassigned)

References

()

Details

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
Group: core-security
Component: General → Untriaged
Could you please try with Firefox 17?
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.
Component: Untriaged → Location Bar
Blocks: useragent
No longer blocks: useragent
(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
Status: UNCONFIRMED → NEW
Has STR: --- → yes
Component: Location Bar → Menus
Ever confirmed: true
context menus should likely be closed when the focused element changes. Could be a platform bug, more than a frontend one.
(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.
See Also: → 1238388
You need to log in before you can comment on or make changes to this bug.