Unable to paste images from drive to Pasteboard.co
Categories
(Core :: DOM: Editor, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr102 | --- | unaffected |
| firefox106 | --- | unaffected |
| firefox107 | --- | wontfix |
| firefox108 | --- | wontfix |
| firefox109 | --- | wontfix |
People
(Reporter: sbadau, Unassigned, NeedInfo)
References
(Regression)
Details
(Keywords: regression)
Attachments
(1 file)
|
3.12 MB,
image/gif
|
Details |
Screen recording with the issue
Found in
- Firefox 107.0b6
Affected versions
- Nightly 108.0a1
- Firefox 107.0b6
Tested platforms
- Affected platforms: macOS 11.7, Windows 10, and Ubuntu 16.04
Steps to reproduce
- Navigate to https://pasteboard.co/
- Copy an image from the drive (Ctrl+C)
- Focus pasteboard.co website and paste the image (Ctrl+V)
Expected result
- The image should be displayed in the pasteboard.co website.
Actual result
- The image is not displayed in the pasteboard.co website. The following error is displayed: "No image data was found in your clipboard, copy an image first (or take a screenshot). "
Regression range
- I'll look for a regression range as soon as possible.
Additional notes
- Copy and paste through drag and drop is done without any issues.
|
Reporter | |
Updated•2 years ago
|
|
|
Reporter | |
Comment 1•2 years ago
|
||
Narrowed integration regression to:
Last good revision: 4d1e93c629daa361f9acd60c1f4e2c594f3bd312
First bad revision: 4bfcb4ab080ffa3b69f831c840d1212e94fc7199
Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=4d1e93c629daa361f9acd60c1f4e2c594f3bd312&tochange=4bfcb4ab080ffa3b69f831c840d1212e94fc7199
|
||
Comment 2•2 years ago
|
||
:masayuki, since you are the author of the regressor, bug 1789967, could you take a look?
For more information, please visit auto_nag documentation.
|
||
Comment 3•2 years ago
|
||
:mccr8 could this be triaged for priority/severity?
Next week is RC week for 107 and would like to know the expectations around this bug
|
||
Comment 4•2 years ago
|
||
It doesn't sound that severe to me, but shipping a regression doesn't seem good if we can avoid it. I don't know how tricky it will be to fix this. Hsin-Yi might have a better idea of prioritization for this issue.
|
||
Comment 5•2 years ago
|
||
It seems that this is a traditional bug of HTMLEditor which was hidden in most cases before bug 1789967.
After stopping collapsing Selection at HTMLEditor::Init call, the odd handling of HTMLEditor becomes major than before, that is the case when Selection has no ranges.
|
|
||
Comment 6•2 years ago
|
||
Unfortunately, it seems that we cannot fix this in our side.
The web site creates an <div class="pastearea" contenteditable></div> only in Gecko (I don't see the element in Chrome with the Inspector) to get the pasted image. It's created at end of the <body>, which had collapsed Selection automatically before the fix of bug 1789967. However, the web site never sets Selection explicitly. Therefore, the editable element never gets caret and HTMLEditor cannot paste given image into it. Additionally, Chrome does nothing when pasting without Selection ranges. Therefore, automatically adjusting Selection for this site would break some web apps. Therefore, we can do nothing in Gecko level.
I think that we should contact the site to initialize Selection by themselves, and if the fix cannot be landed soon, I think that we should create new intervention to make Selection collapse into it in the domain like:
getSelection().collapse(document.querySelector("[contenteditable]"), 0);
|
|
||
Comment 7•2 years ago
|
||
I don't know the exact timing of the <div class="pastearea" contenteditable> is created and inserted into the tree. If it's done while loading the document, modifying Selection in a load event listener emulates the traditional behavior. Otherwise, perhaps, first keydown of Ctrl key is a good timing to do it.
|
|
||
Comment 8•2 years ago
|
||
Setting 107 to fix-optional if something more comes out of the investigation.
:masayuki has there been any further updates? Have you reached out to the web compat team with your findings?
|
||
Comment 10•2 years ago
|
||
(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #9)
I notified hsinyi, but now she is in PTO.
Sorry that I was late here.
Hi Dennis, we appreciate help from the webcompat team. Would you please help us to move this along, see comment 6?
|
|
||
Comment 11•2 years ago
|
||
Set release status flags based on info from the regressing bug 1789967
|
||
Comment 12•1 year ago
|
||
There is nothing we can do here, and the site itself has to fix it. I'll send them an email, but that might not work out too well - or at least not too quickly.
This isn't a very popular application, and most of it works just fine. I assume the workflow of pasting images into it is relatively rare as most people probably will drag-and-drop or use the file picker, so it's not like this is completely broken in Firefox. I'll set this as P3 for now just so that it doesn't blink red on Release Management dashboards.
|
|
||
Updated•1 year ago
|
|
|
||
Updated•1 year ago
|
Description
•