In the past, we had issues with this when users were using some privacy-related extensions. Could you please try that in an anonymous window and paste the logs here if possible?

No security plugins installed in Chrome, In Firefox there is Ghostery but disabling it does not change the result.
But I have found the cause: I was accessing coder with the http protocol, and this raises the Content-Security-Policy issue.
Switching to https solved the problem, even if the certificate is self-signed (I'm testing on my laptop).
Before 2.8.0 it was working also in http... I don't know if now the http is abandoned by coder, but for me the problem was resolved.
Thanks for your suggestion and your time.
Kudos to everything for this great software!

I have encountered the same issue using coder over http. Is this expected or is it a regression?

@renesas-brandon-hussey this is expected because the native clipboard API only works over secure connections but we are thinking on how to improve this experience when this happens.

@BrunoQuaresma thanks for the quick reply. This was working in previous versions over http so I'm guessing this was intentionally changed in v2.8.0? Do you have a recommended workaround?

🤔 Hm.... interesting... cc.: @Parkreiner

@renesas-brandon-hussey So, it's a little hard to say at this point, and part of it might actually be browsers tightening up their own security standards. The core logic for interacting with the clipboard comes from our useClipboard file, which from the history, has only ever had three commits associated with it:

• Initial creation
• Quick codebase-wide code reformatting
• My commit, which ended up focusing on cleaning up timeout logic more consistently and handling some accessibility concerns

Per MDN, the native browser clipboard API is only available via HTTPS. We have a workaround for (much) older browsers that don't have the new clipboard API, but the older API that makes the workaround possible is officially deprecated, and I imagine it's already being removed from newer browsers

So, it seems like increasingly, HTTP users might be put in an awkward spot, where they can't use the newer browser clipboard API for security reasons, but the workaround has also been completely removed. I'm happy to look into whether there might be even more workarounds, but I know the one we used was fairly standard.

@mikitex70 @renesas-brandon-hussey I was looking at the PR, and I noticed one line of code that might be affecting things. All of what I said still applies long-term, but there might be a fix we can do now

Just to make sure: even when the text fails to get copied, is the UI still updating to make it look like the clipboard got updated?

@Parkreiner

Just to make sure: even when the text fails to get copied, is the UI still updating to make it look like the clipboard got updated?

Yes, the copy-to-clipboard icon is changing to a check mark.

Also, just FYI, I created a Coder instance using v2.7.2 and verified this issue does not occur with that version. This is using the same version of Firefox for both Coder v2.7.2 and v2.8.2.

@renesas-brandon-hussey Perfect. I think I found the issue – will be making a hotfix in the next few minutes

@renesas-brandon-hussey @mikitex70 Just fixed an issue with the HTTP fallback. Please let us know if you still run into any problems!

Tested the coder 2.8.3 Docker image, the problem persists when I use the http protocol: the copy icon does not copy the token in the clipboard and in the browser console there are still errors regarding a content blocked by Content-Security-Policy rules.
With https all is fine, as before.

I'm sorry about all this. I thought I had fixed the copy logic (there isn't much else that has changed), and at this point, the only thing I can think of is that somehow, the CSS put in place to prevent UI flickering during the HTTP-only approach is causing some of the native DOM methods to fail

I was already planning to finish up a revamp of our test suite for functionality like this by the end of today, but I'm going to spend more time making sure the HTTP-only edge case gets addressed thoroughly. Hoping to have all that done by the end of today

Internally, we've also been talking about bringing in clipboard.js to simplify some of this logic, and make things less brittle. I think we're at the point where it does make sense to bring it in, but I also think that we need good tests in place to make sure the swap doesn't cause a regression. If I can squeeze the library swap in today, I will, but my goal right now is just restoring the old functionality (even if that requires a full revert)

Update: the automated testing is still in the works (definitely want test cases for when the code runs in non-secure contexts), but in the meantime, I did a fair bit of manual testing. It's just, no matter what I did, I couldn't get the fallback method to fail, even when manually triggering the fallback, and no matter what styling was present

I'm still looking into this, but this is going to be the new path forward:

• Revert the anti-flicker styling, since we didn't seem to have any issues until it was added
• Add a full test suite for all expected functionality (including tests for HTTP-only connections)
• Use the test to ensure there are no regressions when moving the codebase to clipboard.js

@Parkreiner was the work in this ticket included in the v2.8.3 build? I tried out 2.8.3 and noticed the issue still existed. I did not comment because when I looked at the changes that went into 2.8.3 I didn't think this work was included.

Sorry for the late reply, but that would be it. I thought I had squeezed the PR in before the release got cut, but it didn't make the cutoff

I have been talking to the product team to see when a new release can be cut, though, and I am planning to spend this Sunday on getting all the clipboard work done and squared away, so that these regressions don't happen again

Not sure if this is covered by the PR, but in addition to be able to use the copy button, it would be nice if focusing the input box allows you to manually copy the token (as a fallback).

Changes for this issue have been finalized, and we have tests in place now for both HTTP and HTTPS. The fixes should be part of the next release happening soon

Still, what I mentioned about our workaround being officially deprecated and at risk of being removed still holds true. It ended up being out of scope for this issue, but in addition to what @mafredri said, having an alternative way of getting the token will just help with future-proofing deployments in general. That will get covered in a future PR

I've updated to v2.8.5 and this issue is fixed. Thanks!