1941883 - Cut/paste of links not working properly in Yahoo web mail

Status: NEW

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

Description

[Jonathan]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:134.0) Gecko/20100101 Firefox/134.0

Steps to reproduce:

I copied a link I wanted to send to a friend using Yahoo web mail

Actual results:

Instead of the link pasting in the location I wanted, it is pasted ABOVE the body of the message

Expected results:

The link should b pasted where I place the cursor NOT at the top of the message. This began happening when v134.0 64 bit was released and has continued with the update to 134.0.1 yesterday

Comment 1

[Jonathan]

This has been reported to Yahoo mail as well

Comment 2

[Jonathan]

In addition to links erroneously pasted, cut/paste of text in the body of Yahoo web mail places words vertically letter by letter instead of the way its supposed to work

Comment 3

[Sean Feng [:sefeng]]

Hi Jonathan, I can't reproduce the issue. Can you be more specific about what you did, or maybe attach a video about this? Here's what I did https://drive.google.com/file/d/151sXFQ8upXufRD7eJ7Fai-aWgl7o1ZXU/view?usp=sharing

Also this sounds like an regression, if you can use https://mozilla.github.io/mozregression/install.html to find the regression range (no pressure), that'd be great for us!

Thanks

Comment 4

[Jonathan]

Sean

Are you using Firefox for Mac? I just tried pasting a link to a message and it automatically lands at the top instead of where its supposed to go. I've done Google searches for Firefox cut/paste issues and many have said this has been a problem for a long time, though I didn't experience it until v134.0 was released for Mac..it might also be associated with macOS 15.2 which updated a few weeks ago. I'd recommend you test using a Mac running the most current OS and see if you can replicate it

Comment 5

[Jonathan]

I just noticed the browser updated yesterday to 134.0.2 but the problem still persists

Comment 6

[Sean Feng [:sefeng]]

thanks Jonathan. I just test this again. I was also running macOS 15.2 with Firefox 134.0.2. Here's the recording. I still don't reproduce this.

I wonder if it's caused by the content in the clipboard. Where did you "copy" your link? Maybe it's stored in the clipboard with a different format than mine, so I can't reproduce it.

Comment 7

[Jonathan]

Attachment: Screenshot 2025-01-23 at 9.40.31 AM.png

This is the screen shot using Safari

Comment 8

[Jonathan]

Attachment: Screenshot 2025-01-23 at 9.43.21 AM.png

This is the screen shot with Firefox

Comment 9

[Jonathan]

Thanks but its clearly a problem with Firefox..I just made a screen shot of a test email using Safari and another with Firefox and pasting with Safari works as it should. With Firefox the link gets pasted at the top

Since I'm unable to attach or insert anything here, I've attached both screen shots to the User Story field that has an attach button..take a look and you'll see what I'm talking about

Comment 10

[Zach Hoffman [:zrhoffman]]

Using the steps to reproduce in comment 1, I can reproduce on Linux, macOS, and Windows
From mozregression on Windows (because that range of builds crashes for me on Linux and macOS), the regression started between Nightly build 2020-05-12-21-25-13 and Nightly build 2020-05-13-21-50-59.

Regression range: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=78ca58d04a9b107bc6989c3898852160a742e831&tochange=d1114574b777bb00b85f73733a8bd6a78d2ad87e

One thing to note is that, after the regression, pressing Enter after pasting the link highlights the link, but before the regression, it does not.

Comment 11

[Jonathan]

I have no idea what any of this means..but the fact remains that pasting links or data using Safari works as it should but not on Firefox

Comment 12

[Sean Feng [:sefeng]]

Edgar, do you mind to take a look (if it's reproducible for you)? It just doesn't repro for me...

Comment 13

[Jonathan]

Just updated to macOS 15.3 and the problem still exists..and as shown in the screen shots, pasting links works properly with Safari but not Firefox

Comment 14

[Edgar Chen [:edgar]]

Attachment: screen_recording_not_able_reproduce.mov

I could not reproduce the issue, either.
I also noticed the UI on my side is a bit different than the screenshot provided in comment 7 and comment 8.
(The arrow direction of fullscreen button on the top-right corner is different)

Perhaps we are accessing different versions of yahoo mail?

Zach, since you can also reproduce the issue, do you have the same UI as the one Jonathan has?

Comment 15

[Zach Hoffman [:zrhoffman]]

Update the reproduction URL (though I can reproduce from the popup, too)

Comment 16

[Zach Hoffman [:zrhoffman]]

Attachment: reproduction.mkv

Yes, my UI looks pretty much the same (and I'm testing from https://mail.yahoo.com/n/compose , not a popup editor). I am in the US, with locale en-US.

Reproduction video is attached.

Comment 17

[Zach Hoffman [:zrhoffman]]

Attachment: reproduction.webm

(Use an embeddable video format)

Comment 18

[Zach Hoffman [:zrhoffman]]

(The arrow direction of fullscreen button on the top-right corner is different)

To answer explicitly: The arrow direction of my fullscreen button, when the editor is viewedin a popup, is the same as Jonathan's.

Comment 19

[Jonathan]

Re: Yahoo version..I just switched back from the new version to classic and pasting works AS IT SHOULD, so this is clearly an interoperability issue between Firefox and the NEW version of Yahoo web mail

Comment 20

[Zach Hoffman [:zrhoffman]]

Attachment: Reduced testcase

Hi Sean, is bug 1941883 reproducible for you using the reduced testcase?

Comment 21

[Sean Feng [:sefeng]]

Yeah Zach, that's reproducible for me. Really appreciate the reduced testcase!

Edgar will take a look

Comment 22

[Monica Chiorean]

Marking as New as engineering is already looking into it. I was able to reproduce it with the 'Reduced testcase' but not with default yahoo mail.

Comment 23

[Zach Hoffman [:zrhoffman]]

Now that we have a reduced testcase, the regression window I mentioned in bug 1941883 comment 10 does not seem related and should be disregarded.

More info: The regression window was only from using mozregression to bisect directly against https://mail.yahoo.com/n/compose . When testing directly against https://mail.yahoo.com/n/compose , I get the following error in the DevTools console in Nightly build 2020-05-12-21-25-13 or earlier, but not in Nightly build 2020-05-13-21-50-59 or later (and mozregression excludes Nightly build 2020-05-13-09-49-18):

Uncaught SyntaxError: invalid identity escape in regular expression novation_app_9448956a0070502a3ea9.bundle.js:1:3

I have not checked, as per-commit builds that old don't seem to still exist, but I suspect that this is because the regression window includes e365cbeabc4f (Iain Ireland — Bug 1634135: Turn new regexp engine on by default in Nightly r=mgaudet). This regression window is just for support for https://mail.yahoo.com/n/compose in general, as Nightly builds 2020-05-12-21-25-13 and earlier don't support the WYSIWYG auto-linking (which I referred to as link highlighting in bug 1941883 comment 10), since the mail client is broken, likely by that error.

Comment 24

[Edgar Chen [:edgar]]

Attachment: compose-save.zip

Zach helped to obtain the new Yahoo mail page. I attached it here (with Zach’s approval) in case anyone is interested and doesn't have access to the new Yahoo mail UI.

Quote from Zach's mail:

Note that, in order to reproduce the issue locally, I have loaded the page from a local webserver (I use python -m http.server) using the save as the web root, as WYSIWYG auto-linking (and probably the rest of the WYSIWYG editor) does not work when testing from a file:// URI.

Thank you, Zach!

Comment 25

[Edgar Chen [:edgar]]

Attachment: Reduced testcase 2

This is another reduced test case, this is based on the one from comment #20 with some modification to make it closer to the web site behavior.

Comment 26

[Zach Hoffman [:zrhoffman]]

FWIW, WebKit reproduces the bug in the first Reduced testcase, but not in Reduced testcase 2. So maybe both testcases should be WPTs, for webcompat?

Comment 27

[Edgar Chen [:edgar]]

When handling pasting, the yahoo mail saves the current caret position and tries to redirect the paste handling to a hidden contenteditable by switching focus to it. It then moves focus back to the email body and extracts the pasted content from the hidden contenteditable.

          catchEvent(e) {
            switch (e.type) {
              ...
              case 'paste':
                this.saveCaret(!1),
                this._handlePasteEvent(e);
                break;
              ...
              case 'blur':
                this.restoreCaret();
                break;
              ...
            }
          },
  
          _handlePasteEvent(e) {
            e.pastedFiles = R(e);
            const t = window.getSelection(),
            {
              isCollapsed: a,
              anchorNode: s,
              anchorOffset: o,
              focusNode: n,
              focusOffset: r,
              rangeCount: i
            }
            = t;
            e.savedSelection = {
              isCollapsed: a,
              anchorNode: s,
              anchorOffset: o,
              focusNode: n,
              focusOffset: r,
              rangeCount: i
            },
            e.pastedFiles.length &&
            e.preventDefault(),
            e.multiLineText = e.clipboardData &&
            oe.test(e.clipboardData.getData('text/plain')),
            this._redirectToPasteBin(e)
          },

          _redirectToPasteBin(e) {
            this._pasteBin.focus(),
            setTimeout(
              (
                () => {
                  this.cleanLists(this._pasteBin),
                  this._extractPasteBinContents(e)
                }
              )
            )
          },

However, it also tries to restore the caret position in blur event handler when focus moves away from the email body, which ends up calling into restoreCaret() which update selection and reset the _savedCaret.

          restoreCaret() {
            const e = this._savedCaret;
            if (e) {
              const t = document.createRange();
              t.setStart(e.anchorNode, Math.min(e.anchorOffset, e.focusOffset)),
              t.setEnd(e.focusNode, Math.max(e.anchorOffset, e.focusOffset));
              const a = window.getSelection();
              a.removeAllRanges(),
              a.addRange(t),
              this._savedCaret = null
            }
          }

Updating selection to the contenteditable would cause the focus switch to it, and in this case it is a no op on Gecko, because it happens in blur event handler, I think this is the same as bug 53579. And since the _savedCaret is cleared, so the caret is not able to restore to the original position, so the pasted content is extracted to the beginning of email body.

In Chrome, the restoreCaret() call in blur event handler refocues the email body, causing the content to be pasted into the email body directly instead of the hidden contenteditable. However, I don't think this is what page expects, as it intends to paste content into hidden contenteditable and extracts the pasted content from there. So I think we should still contact the site about this.