Closed Bug 1722535 Opened 3 years ago Closed 3 years ago

Pasting into special input fields not possible since v90 when I have formatted text in clipboard

Categories

(Core :: DOM: Editor, defect, P2)

Product:
Core
Component:
DOM: Editor
Version:
Firefox 90
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
92 Branch
Tracking Flags:
Tracking Status
firefox-esr78 --- unaffected
firefox-esr91 --- fixed
firefox90 --- wontfix
firefox91 --- wontfix
firefox92 --- fixed

People

(Reporter: u689427, Assigned: masayuki)

References

(Depends on 1 open bug, Regression)

Details

(Keywords: regression)

Attachments

(2 files)

Bug 1722535 - Make `HTMLEditor` call `HTMLEditUtils::GetBetterInsertionPoint()` with an editing host which is not limited in the `<body>` r=m_kato!
48 bytes, text/x-phabricator-request
RyanVM
: approval-mozilla-esr91+
Details | Review
Bug 1722535 - Add WPT to test basic edit commands in `<div>` element outside `<body>` element r=m_kato!
48 bytes, text/x-phabricator-request
RyanVM
: approval-mozilla-esr91+
Details | Review

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:90.0) Gecko/20100101 Firefox/90.0

Steps to reproduce:

I copy (Ctrl+C) any text from any Internet page, which is not plain text. For example text which is bold. Or I copy text from MS Word or similar software. Then I paste this text (Ctrl+V) into an input field on a website which accepts formatted text.

I could only reproduce this in input fields based on "CKEditor 4" in a forum software called "Woltlab Burning Board 4.0". And according to this thread, it also occurs in "Weebly" blogs: http://forums.mozillazine.org/viewtopic.php?f=38&t=3076985

This happens only with Firefox version 90, not with 89.x and previous versions.

Actual results:

Nothing is pasted, except when I use Ctrl+Shift+V or paste plain text from Notepad (or similar software).

Expected results:

Text should be pasted (formatted (or not)).

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Editor' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → DOM: Editor
Product: Firefox → Core
Component: DOM: Editor → DOM: Copy & Paste and Drag & Drop
Keywords: regressionwindow-wanted

I tried to reproduce this issue, but couldn't as a paid account is needed for both of the forums mentioned in the Description.

A regression window range was already provided in the Mozilla forum.
"So I ran Mozregression, and it narrowed down the issue to the commit for the following: Bug 1627175 - part 57: Move HTMLEditor::GetBetterInsertionPointFor() to HTMLEditUtils r=m_kato!
"

Has Regression Range: --- → yes
Keywords: regressionwindow-wanted → regression
Regressed by: 1627175
Flags: needinfo?(masayuki)

Set release status flags based on info from the regressing bug 1627175

status-firefox90: --- → affected
status-firefox91: --- → affected
status-firefox92: --- → affected
status-firefox-esr78: --- → unaffected

You can test it here: https://t1p.de/3gm8 (shortened URL)

Just copy something from above the editor field and try to paste it in it. It will work with Ctrl+Shift+V, but not with Ctrl+V when using FF 90, but everytime in FF 89 and below.

Take a look ASAP.

Assignee: nobody → masayuki
Component: DOM: Copy & Paste and Drag & Drop → DOM: Editor
Flags: needinfo?(masayuki)
Severity: -- → S2
Priority: -- → P2
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

In the paste event listener, the form inserts <div> element after <body contenteditable>. So, it creates the DOM tree as:

<html>
<head></head>
<body contenteditable>
</body>
<div id="cke_pastebin"></div>
</html>

This is considered here in ckeditor.js:

    getAscendant: function (a, e) {
      var b = this.$,
      c;
      if (!e) b = b.parentNode;
      for (; b; ) {
        if (b.nodeName && (c = b.nodeName.toLowerCase(), typeof a == 'string' ? c == a : c in a)) return new CKEDITOR.dom.node(b);
        try {
          b = b.parentNode
        } catch (d) {
          b = null
        }
      }
      return null
    },

its caller is:

(CKEDITOR.env.webkit
   ?  (i.append(j),
     j.addClass('cke_editable'),
     i.is('body') || (
     f = 'static' != i.getComputedStyle('position')
       ? i
       : CKEDITOR.dom.element.get(i.$.offsetParent),
     g = f.getDocumentPosition().y))
   : i.getAscendant(CKEDITOR.env.ie || CKEDITOR.env.opera ? 'body' : 'html', 1).append(j)

i is div#wcf7 which is editing host which you see in the form.
j is the div#cke_pastebin which is inserted after <body>.

Then, it moves selection into the div#cke_pastebin, set contenteditable to true, and finally move focus/selection into it. So, this is part of bug 1634351.

Depends on: editing-outside-body

Previously, HTMLEditor::GetBetterInsertionPoint() didn't check whether
given point is in an editing host or not. However, now
HTMLEditUtils::GetBetterInsertionPoint() does it with editing host which
is returned by HTMLEditor::GetActiveEditingHost(LimitInBodyElement::No).
However, the old behavior is exactly same as
HTMLEditor::GetActiveEditingHost(LimitInBodyElement::Yes) if editing host
is outside the <body> element.

For taking back the original behavior, we should call the method with the
result of the latter.

Pushed by masayuki@d-toybox.com: https://hg.mozilla.org/integration/autoland/rev/e645abc7664b Make `HTMLEditor` call `HTMLEditUtils::GetBetterInsertionPoint()` with an editing host which is not limited in the `<body>` r=m_kato https://hg.mozilla.org/integration/autoland/rev/3bdd88ac1297 Add WPT to test basic edit commands in `<div>` element outside `<body>` element r=m_kato
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/29864 for changes under testing/web-platform/tests

https://hg.mozilla.org/mozilla-central/rev/e645abc7664b
https://hg.mozilla.org/mozilla-central/rev/3bdd88ac1297

Status: ASSIGNED → RESOLVED
Closed: 3 years ago
status-firefox92: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → 92 Branch

Can someone help me understand the status related to ESR 91?
It's marked as affected, but not wontfix or fixed.
At a minimum I'd expect this to be fixed in ESR 91.1 (right?)

(In reply to csmaclaga from comment #12)

Can someone help me understand the status related to ESR 91?
It's marked as affected, but not wontfix or fixed.
At a minimum I'd expect this to be fixed in ESR 91.1 (right?)

Due to the fixed timing, it was too late for 91 release. However, yes, this should be fixed in ESR 91 branch too since this is a regression.

Upstream PR merged by moz-wptsync-bot

Does it mean, that normal users with no option of switching to nightly/beta have to wait one month for a fix and use other browsers for this period? Can't/won't the fix be backported to Fx91 earlier?

Please nominate this for ESR91 approval when you get a chance.

Flags: needinfo?(masayuki)

Comment on attachment 9233972 [details]
Bug 1722535 - Make HTMLEditor call HTMLEditUtils::GetBetterInsertionPoint() with an editing host which is not limited in the <body> r=m_kato!

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: This is a new regression starting from 90.
  • User impact if declined: User cannot paste rich text editor if editor creates temporary editable element to receive user input off screen outside <body> element, user can input nothing. I.e., user input does not work as expected.
  • Fix Landed on Version:
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Just partially take the traditional behavior back with relaxing the new check of editing host.
  • String or UUID changes made by this patch: none
Flags: needinfo?(masayuki)
Attachment #9233972 - Flags: approval-mozilla-esr91?
Attachment #9233973 - Flags: approval-mozilla-esr91?

Comment on attachment 9233972 [details]
Bug 1722535 - Make HTMLEditor call HTMLEditUtils::GetBetterInsertionPoint() with an editing host which is not limited in the <body> r=m_kato!

Approved for 91.1esr.

Attachment #9233972 - Flags: approval-mozilla-esr91? → approval-mozilla-esr91+
Attachment #9233973 - Flags: approval-mozilla-esr91? → approval-mozilla-esr91+

I just installed the update to v92 and now it works again. :)

Thanks to everyone involved in the fixing!

Could we perhaps add telemetry whether execCommand is used outside body often?

Flags: needinfo?(masayuki)

(In reply to Olli Pettay [:smaug][bugs@pettay.fi] from comment #22)

Could we perhaps add telemetry whether execCommand is used outside body often?

I think it's possible, but why only execCommand? execCommand kicks same action as user's input, so I think we should count how percentage of HTMLEditor instance worked with elements outside body at least once for any actions.

Flags: needinfo?(masayuki) → needinfo?(smaug)

I guess I can clear the needinfo :) We didn't add any telemetry and haven't needed it.

Flags: needinfo?(smaug)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: