Copy-pasting a URL (Cltr-L Ctrl-C) while the page is still loading fails
Categories
(Firefox :: Address Bar, defect, P1)
Tracking
()
People
(Reporter: post+mozilla, Assigned: mak)
References
(Regression)
Details
(Keywords: regression)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0
Steps to reproduce:
Often I open a website mostly to get its URL copied so I can link to it from somewhere else. So I hit Ctrl-T to open a new tab, enter stuff in the awesome bar until I find the right page, and then I hit Enter, Ctrl-L, Ctrl-C before the page is even done loading.
I have reproduced this right now with https://github.com/rust-lang/rust/pull/61041:
- Copy some other stuff into the clipboard.
- Open new tab, enter stuff into awesome bar until that suggestion appears, use arrow keys to navigate it, hit enter.
- While page is still loading, hit Ctrl-L and then Ctrl-C.
- Go elsewhere and paste (Ctrl-V).
Actual results:
For some weeks or months now, when I do this, in many cases Firefox ends up not copying things to the clipboard. So the "other stuff" gets pasted. I tried doing these steps slowly (with a notable pause between any keystrokes, like around 0.3s), and the issue still happens, so this does not seem to be some kind of async-based race condition as I first thought.
Ctrl-L does mark the URL bar, but Ctrl-C just has no effect. I have to do Ctrl-C again after loading is done to make it copy anything.
Expected results:
The URL should get pasted.
This has already almost lead to me copy-pasting very private data and passwords into a chat field and hitting enter, because I was sure I had copied the URL. Doing nothing on Ctrl-C even though text is selected can have severe consequences.
Updated•5 years ago
|
Comment 1•5 years ago
|
||
Probably due to the quantumbar rewrite in 68, so I'll tentatively mark this as being regressed by the quantumbar release.
Could you try reproducing this on a recent Nightly, please? Maybe we've inadvertently fixed it since 69.
Comment 4•5 years ago
|
||
I found a couple of dupes. Bug 1572477 is filed against 68, evidence that this is indeed a quantumbar regression.
Updated•5 years ago
|
Comment 5•5 years ago
|
||
I've run into this as well and I must say that the experience is rather jarring. I can help with reproducing this issue, if necessary.
Could you try reproducing this on a recent Nightly, please? Maybe we've inadvertently fixed it since 69.
The issue is still present with the current nightly (70.0a1, 20190824215209).
Updated•5 years ago
|
Comment 8•5 years ago
|
||
I'm also experiencing this issue
Assignee | ||
Updated•5 years ago
|
Comment 10•5 years ago
|
||
Thanks to the linked bug report, I learned that you can easily workaround the problem by going to about:config and disabling browser.urlbar.quantumbar. Thank goodness!
Assignee | ||
Comment 11•5 years ago
|
||
That pref is going away, not a solution.
Comment 12•5 years ago
|
||
May I submit a request to not remove that preference until this bug is fixed? The bug is very disruptive to my workflow, and I'd rather stop updating Firefox than have to deal with it again.
Assignee | ||
Comment 13•5 years ago
|
||
it's not possible, that train has shipped, we'll try to look into this bug ASAP, considered the number of reports.
Assignee | ||
Comment 14•5 years ago
|
||
I'll start investigating this
Assignee | ||
Comment 15•5 years ago
|
||
This should have been fixed by the patch in bug 1573753.
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Updated•3 years ago
|
Description
•