unable to copy jsx on https://heroicons.com/

[srkrishnan]

hello,

1). To reproduce problem open https://heroicons.com/
2). search for icon
3). mouse hover icon ,click jsx button

able to copy on other browser

[vannilla]

Wrong subforum, but anyway:

Code: Select all

TypeError: navigator.clipboard is undefined

[Moonchild]

Off-topic:

Wrong subforum

moved.

[Moonchild]

We do not allow access to the clipboard data for security reasons. As such we do not implement navigator.clipboard, only methods of the API to set clipboard contents. I do not see why this website would want to read the clipboard for the intended function (which is what navigator.clipboard allows. It's a read-only property to get data out of the clipboard, not copy stuff to it) so that's a little suspect.

The risk here should be obvious: any open website would be able to monitor the system clipboard by polling this property and steal your data. This would require strict permission control on a per-site basis which would still not be desirable (in case of sites getting compromised, etc.). Allowing access to clipboard data from remote content is simply not safe.

[Enobarbous]

I do not see why this website would want to read the clipboard for the intended function (which is what navigator.clipboard allows. It's a read-only property to get data out of the clipboard, not copy stuff to it) so that's a little suspect.

They use navigator.clipboard.writeText() to write the svg to the clipboard
As far as I see in mdn, in firefox the use of "write" and "writeText" is allowed, and "read" is disabled behind the pref. It might be worth doing the same? Or just always return an empty object, regardless of the actual contents of the clipboard.
And add a query to Permissions...

[Moonchild]

You don't seem to understand. We do not implement navigator.clipboard at all at this point.

Copying data to the clipboard is done with document.execCommand("copy").
If you put the execCommand() call inside a click event handler, you don't need any special permissions (script-initiated would need permissions for security reasons - it has to be a user interaction to initiate it (without delay); we simply deny this kind of request and throw an error).

For more information see also https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Interact_with_the_clipboard
Note the remark at the top about navigator.clipboard not being implemented in all browsers because it's a recent addition to the spec for web interaction.

[Enobarbous]

You don't seem to understand. ... Note the remark at the top about navigator.clipboard not being implemented in all browsers because it's a recent addition to the spec for web interaction.

I understand all of that. But well, it's the new fancy api (tm) and it's not the first site to use it. Sooner or later something will have to be done about it.
Plus, it's been partially implemented since ff63, that is just under 5 years now. It's not that "new".

[Moonchild]

Yeah and we're not the ones coming up with new shinies every week.
I'm sure sooner or later it will be implemented. But it doesn't have priority right now. We have bigger fish to fry.
As long as usage is still low, it will be on the back-burner out of necessity. We have to work reactive in most cases, as in implement APIs when they are actually in use at some scale. See also the header "Core work" on https://www.palemoon.org/roadmap.shtml
However, if it is important to people, everyone is welcome to chip in and help implement it into UXP. Adding another DOM interface should not be overly complex even for someone relatively new to our code, with the guidance of the relevant implementation bug on Mozilla's bugtracker.

[SemiKebab]

I also would be grateful to see navigator.clipboard implemented. Probably just the writeText() method, as write() seems less useful, and I really don't feel confident with the read methods…

A few years ago, I was quite reluctant with JS clipboard write ("what if I had something important in the clipboard?"), but I have to admit I got really used to this feature. More and more sites use it, to copy emojis, temp email addresses, anchor links…

Note that clipboard write could already be achieved previously, but it was much more complicated, whereas it can now be a one-liner (and it's async, which is probably justified).

Some refs:

• https://stackoverflow.com/questions/400 ... 2#30810322
• https://fr.wikipedia.org/w/index.php?ti ... =207455522

[Moonchild]

It's on our radar.
Issue #2361 (UXP)
If you want to help out with a pull request, it'd be greatly welcomed!

[SemiKebab]

The feature has been implemented into UXP in November 2023 (BTW, thanks!), though, why is it still not present in Pale Moon?

[RealityRipple]

The feature has been implemented into UXP in November 2023 (BTW, thanks!), though, why is it still not present in Pale Moon?

See viewtopic.php?f=62&t=30568

Personally, I think the spec is a major privacy and security problem (as my shot-down "dummy" option attests to).

[SemiKebab]

That post seems to be (mainly) about read access for extensions.

I was thinking about write access for web content, which is the most basic (and also probably the most used) functionnality. I thought we all agreed it was ok to implement it?

[RealityRipple]

Final implementation of one requires final decision on the other. I think you can temporarily enable it through about:config, though.

[Nigaikaze]

The feature has been implemented into UXP in November 2023 (BTW, thanks!), though, why is it still not present in Pale Moon?

It is currently scheduled to be included in the upcoming release of Pale Moon 33.0.0.

[Moonchild]

The feature has been implemented into UXP in November 2023 (BTW, thanks!), though, why is it still not present in Pale Moon?

This is how development works when you're not shoving nightly/alpha/untested builds of software out to everyone. Changes will be released when development releases are ready. In this case it'll be the next milestone.