Repository: electron
Issue: [Feature Request]: Efficient usage of X11 selections for electron apps
Labels: enhancement :sparkles:,platform/linux

### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [X] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a feature request that matches the one I want to file, without success.

### Problem Description

Currently, when an image is copied, many major electron applications only offer image/png as an image target (you can test this by running: `xclip -o -target TARGETS -selection clipboard` after you copied something — e.g. an image that isn't PNG).

**Why is this a problem?:**   
https://www.reddit.com/r/discordapp/comments/rgqwk0/please_stop_this_nonsense_discord/
When e.g. an image is a small JPEG, a application the user wants to paste into can not ask for that but only for PNG cause the electron using application only offers — in all cases I tested — PNG and not JPEG as a target. This means that a 430 KB JPEG might be converted to a 6.5 MB PNG as seen in the Reddit post I linked to.

### Proposed Solution

I think there is no easy solution but some ideas:
1) Electron handles more (or most) of the selection stuff meaning that developers using electron can ignore them (as they already kinda do?). Biggest pro: New formats can be added fast and all electron apps can support them after an electron update (easily).
I suggest that some of the targets that Firefox offers are added as well as targets for new formats like an image/jxl target for JPEG-XL. Maybe we can be clever and list the best image target first/last e.g. when we have a JPEG display image/jxl, then image/jpeg and then image/png. Applications filtering for image/ targets would thus see image/jxl first (which I put first cause it is backwards compatible to JPEG and always saves space). 
I guess text/html could also be parsed to find out what the original format of the image was and then ask again for the image but that would be... a lot of text to parse in some cases (and I guess it would be better to just introduce a new target containing the file format of the image if we would go that route.)...

2) Let the end user define which selections an electron app should provide
Pro: If it could be implemented in a clever way, newer formats might be supportable without apps updating the electron version they use.

### Alternatives Considered

A) Asking the developers behind every (at least major) electron applications to add code for providing additional selection targets.

B) Change something in the documentation which encourages devs to at least take into consideration that there is more than PNG when it comes to images and provide a list of which targets are recommended to implement.

### Additional Information

Read more about selections here: https://www.uninformativ.de/blog/postings/2017-04-02/0/POSTING-en.html or https://en.wikipedia.org/wiki/X_Window_selection or https://www.freedesktop.org/wiki/Specifications/ClipboardsWiki/

All targets Chromium (which electron uses) offers when an image is copied:
```
TIMESTAMP
TARGETS
SAVE_TARGETS
MULTIPLE
image/png
text/html
```

This is what Firefox offers:
```
TIMESTAMP
TARGETS
MULTIPLE
SAVE_TARGETS
text/html
text/_moz_htmlinfo
text/_moz_htmlcontext
image/png
image/bmp
image/x-bmp
image/x-MS-bmp
image/x-icon
image/x-ico
image/x-win-bitmap
image/vnd.microsoft.icon
application/ico
image/ico
image/icon
text/ico
image/jpeg
image/tiff
image/avif
image/webp
audio/x-riff
```