Closed Bug 1573753 Opened 5 years ago Closed 5 years ago

Unable Copy URL in Addressbar , Ctrl+C or Copy Menu not worked

Categories

(Firefox :: Address Bar, defect, P1)

Product:
Firefox
Component:
Address Bar
Type:
defect
Points:
3

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 72
Iteration:
72.1 - Oct 21 - Nov 3
Tracking Flags:
Tracking Status
firefox-esr68 71+ verified
firefox70 --- wontfix
firefox71 + verified
firefox72 --- verified

People

(Reporter: majid, Assigned: mak)

References

(Regression)

Details

(Keywords: regression, Whiteboard: regression)

Attachments

(4 files)

Unable Copy URL in Addressbar , Ctrl+C or Copy Menu not worked.mp4
1.36 MB, video/mp4
Details
bandicam 2019-10-24 19-28-18-615.mp4
1.57 MB, video/mp4
Details
Bug 1573753 - Copy the urlbar value when pageproxystate is invalid and there's no result. r=adw,dao
47 bytes, text/x-phabricator-request
pascalc
: approval-mozilla-beta+
RyanVM
: approval-mozilla-esr68+
Details | Review
ESR patch
6.81 KB, patch
Details | Diff | Splinter Review

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0

Confirmed by Firefox 69.0b13 (64-bit).
I typed an address and added part of URL by copy+pasted a file name (downloadable file)
Enter. The file will be offered to download.
I confirmed the link exists and is correct
I copy the URL from the address bar.
Old content is still on the clipboard (not the new URL)

Confirmed on Firefox 68.0.2 (64-bit)
It happens so many times every day.

Hey Erkki,

Could you please provide more detailed steps of what exactly you are typing and copy-pasting?
Didn't understand entirely and can't check this issue without correct steps.

Sorry for the inconvenience!

Flags: needinfo?(laaneoks)

Steps:

  1. I uploaded file to a web server (e.g. thisIsLongAndDifficultFileName.zip )
  2. I copy the file name
  3. I want to give the URL to this file to someone else and I want to test (maybe Error 404). I type the beginning of the file (e.g. http://lapselevanemad.ee/temp/ )
  4. I paste the copied filename and URL is now "http://lapselevanemad.ee/temp/thisIsLongAndDifficultFileName.zip"
  5. I press the Enter key to become sure correctness
  6. Firefox launched window to download the file. Confirmed (no typos etc)
  7. I select the whole URL and press CTRL+C (or CTRL+INS or mouse right-click and select "Copy")
  8. I open the text file and paste it (CTRL+V)
  9. Pasted text is "thisIsLongAndDifficultFileName.zip" but expected was "http://lapselevanemad.ee/temp/thisIsLongAndDifficultFileName.zip"

If I change the URL (for example add "t" and delete this then Copy+Paste is successful (the whole URL copied))

Flags: needinfo?(laaneoks)

Hey majid,
I tried to reproduce this issue you're talking about under a screen recording app. Please see the attached file and let me know if I missed any steps, because i could not reproduce the issue.
Furthermore you can record your screen as well using the Bandicam app and attach the video here so we can see the exact steps for the issue.

Flags: needinfo?(majid)

Asking the same info from Erkki as the above comment.

Flags: needinfo?(laaneoks)

My Firefox version: 69.0b16 (64-bit) (Win7)
Please try to click "Cancel" on "file save as" dialog window.

Flags: needinfo?(laaneoks)

If I may, I would suggest re-testing the issue while in Safe Mode. You can find helpful info here : https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode .
Also a fresh new profile could help. You can find more about creating a new profile here : https://support.mozilla.org/en-US/kb/troubleshoot-and-diagnose-firefox-problems#w_6-create-a-new-firefox-profile .

Flags: needinfo?(laaneoks)

Hi,

I have same issue as described here.
Clicking cancel in the Download prompt does not make the URL copyable (neither does clicking OK)

I'm running Firefox 69.0.1 on Win 10 19.03

Hello Christoph,

Can you re-test this issue using the steps from Comment 9 please and let us know what happened?

Thanks.

Flags: needinfo?(c.schwarzenberg)

Hi Andrei,

I tested it with a new Firefox profile - still same issue:
Copying works neither when clicking OK in the file save prompt, nor when clicking Abort.

Flags: needinfo?(c.schwarzenberg)

Hey again Cristoph,

Can you record the steps you did to repro the issue and send us a video?
You can use Bandicam, download it from here : https://www.bandicam.com/downloads/ .

Thanks a lot for the help.

Flags: needinfo?(c.schwarzenberg)

Screen recording of bug

Hi,

here you go: https://bugzilla.mozilla.org/attachment.cgi?id=9104005
Used Firefox 70.0 (x64, Win 10)

Steps:
0:00 - 0:08: Copy "foo" to clipboard and paste it again
0:08 - 0:21 Navigating to manually entered URL, cancelling the file download, copy the address from address bar, try pasting it in new tab -> results in "foo" being pasted instead of address
0:22 - 0:31 In first tab again: Navigate to same URL again, downloading file, copy address, try pasting address in new tab -> results in "foo" being pasted instead of address

Interestingly, this did not work with an exe file, so maybe it is related to the file type? With zip files, it's the same erroneous behaviour.

Flags: needinfo?(c.schwarzenberg)

Hello,

I was able to reproduce this issue on Windows 10 x64, Ubuntu 18.04 x64 and MacOS 15.0 on the release version 70.0, the beta one 71.0b4 and Nightly 72.0a1 (2019-10-24).

I have set a component for this issue in order to get the dev team involved.
If you feel it's not the correct one please feel free to change it.

This is a regression and here is the regression range :
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=38a326f813f6b1fd1400d215730e0105f62eb9c5&tochange=725cc368d14453980d6e0b112edc263a12463ffe

Status: UNCONFIRMED → NEW
status-firefox70: --- → affected
status-firefox71: --- → affected
status-firefox72: --- → affected
Component: Untriaged → Address Bar
Ever confirmed: true
OS: Unspecified → All
Hardware: Unspecified → All
Version: 70 Branch → Trunk

This is something I've seen reported frequently, especially after we enabled the QuantumBar, sometimes we fail to copy the urlbar contents. What I've seen reported more often is it happening when the page is loading, but this case seems to be more static and easier to investigate.

I think it's worth spending time on this considered the many reports around. Just a couple days ago Mark reported a user on Twitter suggesting to disable quantumbar to workaround the problem. Also see bug 1586685.

Points: --- → 5
Priority: -- → P1
See Also: → 1586685
See Also: → 1572961

investigating... note though I'm not yet looking at bug 1572961, because in this bug we have easily reproducible steps it's worth starting from here.
Any report related to copying while the page is loading should move to bug 1572961 and not be handled here.

We seem to bailout here https://searchfox.org/mozilla-central/rev/74cc0f4dce444fe0757e2a6b8307d19e4d0e0212/browser/components/urlbar/UrlbarInput.jsm#1237

Assignee: nobody → mak
Status: NEW → ASSIGNED
Regressed by: 1525018
Whiteboard: regression

The problem is that _loadURL invokes the .value setter, that overrides _resultForCurrentValue. I think this also causes bug 1572961, because _loadURL clears _resultForCurrentValue and valueIsTyped, and while the page is loading pageproxystate is invalid. We end up again in this code branch, that is throwing and not completing a copy.

Flags: needinfo?(majid)
Flags: needinfo?(laaneoks)
Points: 5 → 3
Iteration: --- → 72.1 - Oct 21 - Nov 3

When copying from the input field, when the value has already been confirmed
by the user (either by picking a result or Enter), we cannot use the selected
result information, because it has already been cleared by _loadURL setting
the value to the final one.
If the page already finished loading, pageproxystate is valid and we can use
currentURI, but if the page takes a long time to load, or the load is canceled,
we need a fallback, because we don't want to interrupt the copy operation.

In this case, the current value can be either a valid url or a search string.
If it's a valid url, we can just go through the usual URI handling, trying to
make it nicer. After all, we'd do the same just after the page is done loading.
Otherwise, we fallback to the currently selected value.

This works also if the user is still in the process of selecting a result
and tries to copy from the input field, because on result selection we set
either a valid url or a non-url.

Pushed by mak77@bonardo.net:
https://hg.mozilla.org/integration/autoland/rev/8c2f5b82f33a
Copy the urlbar value when pageproxystate is invalid and there's no result. r=adw

uh, I had pushed the same to Try and it didn't fail https://treeherder.mozilla.org/#/jobs?repo=try&revision=c7db6be7a004806e725a057719d3eea1c8d76916

I see a bunch of minidump.cc:1571: ERROR: MinidumpThread has a memory region problem, but likely a red herring.
Finally I see Hit MOZ_CRASH(Shutdown too long, probably frozen, causing a crash.), this is probably the error cause.

The only thing different I'm doing is that I'm starting a load of a page in a tab, and closing it without waiting for the load to complete, that would be a suprising way to break mochitests, but must be it, because all the rest is trivial. I'll reduce the timeout and wait for the page load.
It's really strange that Try was fine with it, something must have changed in the meanwhile and maybe it introduced a bug somewhere else.

Flags: needinfo?(mak)
Pushed by mak77@bonardo.net:
https://hg.mozilla.org/integration/autoland/rev/202e52093520
Copy the urlbar value when pageproxystate is invalid and there's no result. r=adw

https://hg.mozilla.org/mozilla-central/rev/202e52093520

Status: ASSIGNED → RESOLVED
Closed: 5 years ago
status-firefox72: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 72

Comment on attachment 9104696 [details]
Bug 1573753 - Copy the urlbar value when pageproxystate is invalid and there's no result. r=adw,dao

Beta/Release Uplift Approval Request

  • User impact if declined: Copying from the urlbar sometimes fails, especially on slow loading pages.
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: comment 14 and comment 15, plus copying while a slow page is loading (no example available)
  • List of other uplifts needed: None
  • Risk to taking this patch: Medium
  • Why is the change risky/not risky? (and alternatives if risky): the changes should be safe, but didn't get a long enough Nightly testing period yet.
  • String changes made/needed:

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: We got many reports of this problem, also on Twitter and Reddit.
  • User impact if declined: Copying from the urlbar sometimes fails, especially on slow loading pages. This is annoying for the user.
  • Fix Landed on Version: 72
  • Risk to taking this patch: Medium
  • Why is the change risky/not risky? (and alternatives if risky): Didn't get a long enough Nightly/Beta testing period yet.
  • String or UUID changes made by this patch:
Attachment #9104696 - Flags: approval-mozilla-esr68?
Attachment #9104696 - Flags: approval-mozilla-beta?
Flags: qe-verify+
Blocks: 1572961
See Also: 1572961 →
QA Whiteboard: [qa-triaged]

Let's get it verified on Nightly by QA before taking it into beta, probably in beta 7 to give it a few days of nightly exposure.

tracking-firefox71: --- → +

Thanks again Cristoph for the recording, it helped a lot!

Reproduced the issue on affected Beta 71.0b5 (64-bit based on steps from Comment 15
Verified the fix on latest Nightly 72.0a1 (Build ID:20191029212748) on Windows 10, Mac OS 10.15 and Ubuntu 18.04

  • Checked steps from Comment 15
  • Slow loading sites like: taobao.com
  • Verified expected result from Comment 4

Waiting for uplift to Beta and ESR

Cristoph, with the risk of bothering you, can you give it a shot once more on the latest Nightly? Making sure this fix is good since it is important. Better safe than sorry.
Here is from where you can download the latest Nightly build: http://archive.mozilla.org/pub/firefox/nightly/2019/10/2019-10-29-21-27-48-mozilla-central/

status-firefox72: fixed → verified
Flags: needinfo?(c.schwarzenberg)

Comment on attachment 9104696 [details]
Bug 1573753 - Copy the urlbar value when pageproxystate is invalid and there's no result. r=adw,dao

P1, verified by our QA on Nightly, patch with tests, looks sage enough for beta, uplift approved for 71 beta 6, thanks.

Attachment #9104696 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

Hi,

thanks for all your efforts.

@Timea: Works like a charm :)

Flags: needinfo?(c.schwarzenberg)

Thanks Christoph!

Verified - fixed on latest Firefox Beta 71.0b6 (Build ID: 20191101011821) on Windows 10, MacOS 10.15 and Ubuntu 18.04
Waiting for Uplift to ESR.

status-firefox71: fixed → verified

Comment on attachment 9104696 [details]
Bug 1573753 - Copy the urlbar value when pageproxystate is invalid and there's no result. r=adw,dao

Thanks for the verification. Approved for 68.3esr too.

Attachment #9104696 - Flags: approval-mozilla-esr68? → approval-mozilla-esr68+

Backed out for failing added browser_urlbar_copy_during_load.js:

https://hg.mozilla.org/releases/mozilla-esr68/rev/584b998c3ad2355541e19aaba28678e7000e8c4b

Failure log: https://treeherder.mozilla.org/logviewer.html#?job_id=274144880&repo=mozilla-esr68
Push with failures: https://treeherder.mozilla.org/#/jobs?repo=mozilla-esr68&selectedJob=274144880&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel%2Crunnable&revision=97bca4363e015a7dbde22c364ad1e6800f7846df

[task 2019-11-01T19:31:38.994Z] 19:31:38 INFO - TEST-PASS | browser/components/urlbar/tests/browser/browser_urlbar_copy_during_load.js | Clipboard has the given value: 'http://www.example.com/browser/browser/components/urlbar/tests/browser/slow-page.sjs' -
[task 2019-11-01T19:31:38.994Z] 19:31:38 INFO - Copy the initial part of the url, as a different valid url
[task 2019-11-01T19:31:38.996Z] 19:31:38 INFO - Buffered messages logged at 19:31:38
[task 2019-11-01T19:31:38.998Z] 19:31:38 INFO - Console message: [JavaScript Error: "The character encoding of the HTML document was not declared. The document will render with garbled text in some browser configurations if the document contains characters from outside the US-ASCII range. The character encoding of the page must be declared in the document or in the transfer protocol." {file: "http://www.example.com/browser/browser/components/urlbar/tests/browser/slow-page.sjs" line: 0}]
[task 2019-11-01T19:31:38.999Z] 19:31:38 INFO - Buffered messages finished
[task 2019-11-01T19:31:39.000Z] 19:31:39 INFO - TEST-UNEXPECTED-FAIL | browser/components/urlbar/tests/browser/browser_urlbar_copy_during_load.js | Timed out while polling clipboard for pasted data, got: http://www.example.com/browser/browser/components/urlbar/tests/browser/slow-pa -
[task 2019-11-01T19:31:39.000Z] 19:31:39 INFO - Stack trace:
[task 2019-11-01T19:31:39.001Z] 19:31:39 INFO - chrome://mochikit/content/browser-test.js:test_ok:1587
[task 2019-11-01T19:31:39.002Z] 19:31:39 INFO - chrome://mochikit/content/tests/SimpleTest/SimpleTest.js:putAndVerify:1013

status-firefox-esr68: fixed → affected
Flags: needinfo?(mak)
Attached patch ESR patch — — Splinter Review

The problem is ESR doesn't have bug 1528593, so the test must use textValue instead of value

Flags: needinfo?(mak)

Not sure if I should set the checkin? flag on someone (who?)

Flags: needinfo?(aryx.bugmail)

Bugs which have a patch approved for uplift and that branch not set as fixed / verified show up in the uplift queries used by sheriffs and don't require further action.

Flags: needinfo?(aryx.bugmail)

Verified - fixed on the latest 68.3.0esr (Build ID: 20191105180344) on Windows 10 x64, MacOS 10.13 and Ubuntu 18.04.
Closing this issue as verified - fixed and removing flags.

Status: RESOLVED → VERIFIED
QA Whiteboard: [qa-triaged]
status-firefox-esr68: fixed → verified
Flags: qe-verify+
Regressions: 1637408
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: