1967510 - gemini.google.com - Copy does not work from prompt editing area to prompt input area

Status: VERIFIED FIXED

(Web Compatibility :: Site Reports, defect, P2)

Description

[Sean Feng [:sefeng211]]

This is very similar to bug 1945434, but about pasting it into a different location.

See https://bugzilla.mozilla.org/show_bug.cgi?id=1945434#c13

Comment 1

[Sean Feng [:sefeng211]]

Attachment: testcase.html

I think the issue is, Gemini does something like this in their "copy" event listener,

clipboardData.setData('text/html', '');
clipboardData.setData('text/plain', window.getSelection().toString());

And in their "paste" event listener, they do something like

if (event.clipboardData.types.includes("text/html")) {
   // Use clipboardData.getData('text/html')
} else {
   // Use clipboardData.getData('text/plain');
}

clipboardData.setData('text/html', ''); still creates an entry to the clipboard in Firefox, and it doesn't in Chrome.

Comment 2

[Sean Feng [:sefeng211]]

Edgar, masayuki, thoughts about this? Is this our issue/Chrome issue/something undefined?

Comment 3

[Edgar Chen [:edgar] (PTO 2/2 ~ 2/6)]

Safari also still creates an entry on the clipboard for an empty sting.
And spec doesn't specify that items with an empty string as data should be ignored. So I think it is a Chrome issue.

Comment 4

[Edgar Chen [:edgar] (PTO 2/2 ~ 2/6)]

There's an old Chrome issue: https://issues.chromium.org/issues/40701751. Perhaps it has regressed again.

Comment 5

[Sean Feng [:sefeng211]]

It looks like Webkit creates an entry but with empty content, whereas in Firefox it is the meta tag <meta http-equiv="content-type" content="text/html; charset=utf-8">

I wonder if the above differences cause it to work in Safari but not in Firefox.

I also confirmed in a local build of Firefox such that this issue is fixed if I force Gecko to not generating that entry.

Comment 6

[Edgar Chen [:edgar] (PTO 2/2 ~ 2/6)]

(In reply to Sean Feng [:sefeng] from comment #5)

It looks like Webkit creates an entry but with empty content, whereas in Firefox it is the meta tag <meta http-equiv="content-type" content="text/html; charset=utf-8">

I wonder if the above differences cause it to work in Safari but not in Firefox.

Yes, the content is different, I will check.

Comment 7

[Edgar Chen [:edgar] (PTO 2/2 ~ 2/6)]

Okay, although the content in system clipboard is different, but Gecko still returns an empty string for getData('text/html');, so it looks like the widget code is handling the conversion. From the Web API point of view, our behavior is actually the same as Safari’s on macOS.

I debugged the page a bit and found that it doesn’t handle the paste event directly, but instead lets the browser handle the paste action.
So I suspect the difference is from the Editor which perhaps our Editor always use the HTML data even if it is empty string, I will do more investigation.

---

Edited: Returning an empty string for getData('text/html') is macOS-only behavior, other platforms return whatever data is currently in the system clipboard.

Comment 8

[Edgar Chen [:edgar] (PTO 2/2 ~ 2/6)]

(In reply to Edgar Chen [:edgar] from comment #7)

Okay, although the content in system clipboard is different, but Gecko still returns an empty string for getData('text/html');, so it looks like the widget code is handling the conversion. From the Web API point of view, our behavior is actually the same as Safari’s.

Error, the getData('text/html'); do return a empty string, but the DataTransfer.types doesn't contain text/html on Safari, so I believe this is the root cause. I need to check other platform as well.

(I made some mistake, please ignore this comment)

Comment 9

[Edgar Chen [:edgar] (PTO 2/2 ~ 2/6)]

Attachment: testcase2.html

Comment 10

[Edgar Chen [:edgar] (PTO 2/2 ~ 2/6)]

I need to check the behavior on other platforms as well.

Comment 11

[Edgar Chen [:edgar] (PTO 2/2 ~ 2/6)]

(In reply to Edgar Chen [:edgar] from comment #7)

Okay, although the content in system clipboard is different, but Gecko still returns an empty string for getData('text/html');, so it looks like the widget code is handling the conversion. From the Web API point of view, our behavior is actually the same as Safari’s.

Oh, this is macOS-only behavior, since only macOS uses the data from clipboard cache; other platforms return whatever data is currently in the system clipboard.

So there are two things here,
1). We always wrap string with HTML tags for HTML type when copying, even if the string is empty.
2). Other browser's editors fall back to using text/plain data if text/html is an empty string.

Comment 12

[Sean Feng [:sefeng211]]

Thanks Edgar!

Sounds like you are going to making a change, I'll conclude this as platform-bug then. Let me know if you disagree!

Comment 13

[Randell Jesup [:jesup] (needinfo me)]

Are there any possible workarounds while waiting for a platform-bug fix to ride to release (even if uplifted that will take ~1 month)?

Comment 14

[Edgar Chen [:edgar] (PTO 2/2 ~ 2/6)]

One possible workaround is to add a JS intervention that calls clearData('text/html') on event.clipboardData to remove text/html data when it’s an empty string during copy.

Comment 15

[Thomas Wisniewski [:twisniewski]]

Attachment: Bug 1967510 - add a desktop-only JS webcompat intervention for gemini.google.com to fix copy-pasting between inputs; r?denschub

Comment 16

[Thomas Wisniewski [:twisniewski]]

This doesn't seem to affect Fenix. I can copy-paste just fine there from my earlier prompts to the new-prompt input (but not on desktop). I've added Sean's suggested intervention to the bug for desktop.

Comment 17

[Sean Feng [:sefeng211]]

(It was Edgar suggested the intervention :) )

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/3ebe23ad6824
https://hg.mozilla.org/integration/autoland/rev/43759e8aa63b
add a desktop-only JS webcompat intervention for gemini.google.com to fix copy-pasting between inputs; r=denschub,webcompat-reviewers

Comment 19

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/43759e8aa63b

Comment 20

[Yuval Meshorer]

Attachment: Troubleshooting informatino

Hey guys - wanted to let you guys know that currently pasting on gemini.google.com does not work at all.

I

Comment 21

[Yuval Meshorer]

Hey guys - wanted to let you guys know that currently pasting on gemini.google.com does not work at all.

I (In reply to Yuval Meshorer from comment #20)

Hey guys - wanted to let you guys know that currently pasting on
gemini.google.com does not work at all.

I

(In reply to Yuval Meshorer from comment #20)

Hey guys - wanted to let you guys know that currently pasting on
gemini.google.com does not work at all.

If I go to about:compat and remove the intervention of "Bug 1967510", then pasting works again.

Comment 22

[Yuval Meshorer]

Sorry, I'm new to the forums here and didn't know that uploading an attachment also means sending the comment. And also that you can't update your own comments :)

In short, the current issue is that it seems that the intervention done in https://github.com/mozilla-firefox/firefox/commit/3ebe23ad6824 currently breaks pasting on https://gemini.google.com rather than fixing it.

To prove this, I went to about:compat and disabled the compatibility for gemini.google.com and now pasting seems to work as intended.

I am on version 141.0a1, as seen in the badly pasted 'Troubleshooting information' in one of my previous comments.

Comment 23

[Yuval Meshorer]

I attempted to open a pull request to fix this issue from the commit here: https://github.com/mozilla-firefox/firefox/commit/3a757622f8af107712ae58a6eb1484a17901ef9c
If anyone is interested in continuing this, please feel free :)

Comment 24

[Edgar Chen [:edgar] (PTO 2/2 ~ 2/6)]

(In reply to Yuval Meshorer from comment #21)

Hey guys - wanted to let you guys know that currently pasting on gemini.google.com does not work at all.

I could not reproduce it, pasting on gemini.google.com works on my side.
I also didn't found any suspicious from the information you provided in comment #20.

---

Could you share some more information?

• Where did you copy the data from? (same web page, another web page or another application)
• Where did you paste the clipboard content to? (I guess you paste the content to the prompt input area?)
• It would be helpful if you can help to capture some log,
  • Open about:logging
  • Set log modules to timestamp,sync,Clipboard:5,WidgetClipboard:5.
  • Start logging.
  • (reproduce the issue)
  • Stop logging, which will open profiler in a new tab.
  • Upload local profile.
  • And then share the link to us.

Comment 25

[Yuval Meshorer]

(In reply to Edgar Chen [:edgar] from comment #24)

Hi, sorry for the late reply.

I have looked into this yesterday a bit more and here are my findings:

1. I have noticed that gemini.google.com now works with or without this intervention, thus making it obsolete.
2. I am developing a Firefox extension that "holds" certain events then re-triggers them manually. For example, I "catch" a paste event and then call .setData manually on it. This triggers the error of:

TypeError: 'setData' called on an object that does not implement interface DataTransfer.

3. To answer your questions about the paste itself, it was to the prompt area (the textbox), and the data pasted is just plain text (so I think the source does not matter here?).
4. Reproduced with logs: https://share.firefox.dev/3TvvCyC

It seems like the main issue this change now causes is that Firefox extensions cannot call wrappedJSObject.DataTransfer.setData. Here's a link to a script to reproduce this error: https://pastebin.com/3QSPsBN7 (dump this anywhere in your extension). This will cause pastes to not work.

Note that this works correctly when you disable the gemini.google.com compatibility.

If there is any more information I can provide, please reach out.
And if you want me to file a proper bug report, I will happily do that as well.

Thank you very much for your time!

Comment 26

[Edgar Chen [:edgar] (PTO 2/2 ~ 2/6)]

(In reply to Yuval Meshorer from comment #25)

And if you want me to file a proper bug report, I will happily do that as well.

Yes, please file a separated bug, we could continue discussion there. Thanks!

Comment 27

[Yuval Meshorer]

(In reply to Edgar Chen [:edgar] from comment #26)

Yes, please file a separated bug, we could continue discussion there. Thanks!

Opened https://webcompat.com/issues/162351 :)

Although this was created on a different site (this can be fine, I'm new here :)

Comment 28

[Thomas Wisniewski [:twisniewski]]

Thanks, Yuval! I'll make a patch to remove the Gemini intervention, and will keep an eye out in the future to not let that kind of bug slip through in future interventions.

Comment 29

[Thomas Wisniewski [:twisniewski]]

Attachment: Bug 1967510 - remove our webcompat JS intervention for gemini.google.com; r?denschub

Comment 30

[Edgar Chen [:edgar] (PTO 2/2 ~ 2/6)]

The STR for this bug, where the clipboard data is copied from the prompt editing area, still doesn't work for me without the intervention. Perhaps we should make the extension use case work instead?

Comment 31

[Thomas Wisniewski [:twisniewski]]

Hmm. Ok, I'll take a look, thanks.

Comment 32

[Thomas Wisniewski [:twisniewski]]

Attachment: Bug 1967510 - fix a bug with our gemini.google.com webcompat intervention which can break add-on use of setData on the page; r?denschub

Comment 33

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/c01e03e1bb7a
https://hg.mozilla.org/integration/autoland/rev/7cfdbdda0ddd
fix a bug with our gemini.google.com webcompat intervention which can break add-on use of setData on the page; r=denschub,webcompat-reviewers

Comment 34

[Yuval Meshorer]

@twisniewski thank you very much!

When is this expected to hit Nightly? I'm guessing tomorrow (hence the name)? :)

If so, I'll update tomorrow as to if it works for me or not.

Comment 35

[Thomas Wisniewski [:twisniewski]]

@Yuval, hopefully it will land within the next twelve hours, and make it into tomorrow's nightly, yes. It might take a little longer if there's an unexpected delay, but you'll see the version number of the webcompat addon (easiest to see in about:support) change form 141.2.0 to 141.3.0 once the update is active.

Comment 36

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/7cfdbdda0ddd

Comment 37

[Yuval Meshorer]

Hi @twisniewski, just wanted to say that your solution works!
Validated now with the browser extension. Thank you very very much! Have a fantastic weekend.

Comment 38

[Thomas Wisniewski [:twisniewski]]

You too, thanks Yuval!

Comment 39

[Thomas Wisniewski [:twisniewski]]

Attachment: Bug 1967510 - add a regression test for the bug described in comment 25 of the bug, where addons could not call setData on paste events due to a flaw with our webcompat intervention; r?denschub

Comment 40

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/e758a16d23c4
https://hg.mozilla.org/mozilla-central/rev/3d1868136790
add a regression test for the bug described in comment 25 of the bug, where addons could not call setData on paste events due to a flaw with our webcompat intervention; r=denschub

Comment 41

[amarc]

https://hg.mozilla.org/mozilla-central/rev/3d1868136790

Comment 42

[Thomas Wisniewski [:twisniewski]]

It looks like they have fixed the bug, so we can remove our intervention \o/

Comment 43

[Thomas Wisniewski [:twisniewski]]

Attachment: Bug 1967510 - remove our webcompat copy/paste intervention for gemini.google.com; r?denschub

Comment 44

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/fa9c5cdb882a
https://hg.mozilla.org/integration/autoland/rev/741d746550eb
remove our webcompat copy/paste intervention for gemini.google.com; r=webcompat-reviewers,ksenia

Comment 45

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/741d746550eb

Comment 46

[Raul Bucata]

Verified as FIXED using the RC Build

Tested with:

Browser / Version: Firefox 146.0-candidate build 1
Operating System: Windows 10 PRO x64