1808700 - [Gmail] Quotation marks are not always deleted even if there is no text

Status: NEW

(Core :: DOM: Editor, defect)

Description

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

Notes

• Please see the attachment for more detail.

Found in

• Nightly 110.0a1;

Affected versions

• Nightly 110.0a1;
• Firefox 109.0b8;

Tested platforms

• macOS 12;
• Windows 10;
• Ubuntu 22;

Affected platforms

• macOS 12;
• Windows 10;
• Ubuntu 22;

Unaffected platforms

• N/A;

Preconditions

• Be logged in with a valid account on https://mail.google.com

Steps to reproduce

1. Launch Firefox and go to https://mail.google.com.
2. Click on the Compose button to open a new e-mail.
3. Select the quotation option from the editor.
4. Type some text inside the quotation marks.
5. Press Backspace to delete the text.

Expected result

• The quotation mark should be deleted if there's no text.

Actual result

• The quotation mark is not deleted.

Regression range

• Will look for one as soon as possible.

Comment 1

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

Attachment: Screen Recording 2023-01-05 at 15.47.28.mov

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Odd. When I press Backspace at start of the quotation block, HTMLEditor does not receive the backspace key event. I.e., the event has already been handled by Gmail itself, and Gmail must have failed to delete it by themselves.

Comment 3

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

I tried searching for a regression range but it seems that I can reproduce the issue up until Nightly 63.0a1(2018-07-07).
I think it's safe to assume that this is not a regression.

Comment 4

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

twisniewski: Hi, according to the C++ debugger, the keydown event of Backspace key in this case is prevented its default by a call of preventDefault, thus, preceding internal keypress event is never fired and out builtin editor does nothing. Could you or your team investigate what's going on in the content script? (I mean that the case must be handled in Gmail's JS, but it fails in Firefox. I confirmed that it works in Chrome.)

Comment 5

[Thomas Wisniewski [:twisniewski]]

Pardon the delay here. I just diagnosed this to see what's happening.

This code is preventing default on the keydown event:

      _.w.O3 = function (a) {
        if (_.fv) {
          if (this.ud().Gqa()) return !1;
          if (8 == a.keyCode) {
            var b = this.ud().Ah(),
            c = this.ud().Ea();
            b = b &&
            b.Nh();
            c.firstChild == b &&
            _.OZc(b) &&
            (a.preventDefault(), a.stopPropagation())
          } else if (

Where c is the editable div, and its firstChild is a blockquote.gmail_quote, which all checks out.

This is _.OZc:

      _.OZc = function (a, b) { // a = blockquote element, b = undefined
        var c = _.I6a(a); // returns "\n"
        if (a.getElementsByTagName) // true
          for (var d in HZc) // HZc is {EMBED:true, IFRAME:true, IMG:true}
            if (a.tagName == d || 0 < a.getElementsByTagName(d).length) // can't be true, b is blockquote
              return !1;   // so we don't end up here
        return !b &&       // true (b=undefined)
        ' ' == c ||        // false (c="\n")
        _.y5a(c)           // so this is what's returning true
      };

And _.y5a is:

      _.y5a = function (a) {
        return !/[^\t\n\r ]/.test(a)
      };

So yes, that checks out too. They will see \n and return true, which ends up preventing the default on the keydown event above.

The question is what happens in Chrome to avoid this same outcome.

The answer is that _.fv is false in Chrome (in the first function I list above), while it's true in Firefox. Which means that none of this code will run at all in Chrome.

And what is _.fv? Of course, it's:

    _.fv = _.iq('Gecko') && // also checks for Trident and MSIE and other things

I'm not sure why they would be doing this on Firefox. Presumably it's some old code from when contenteditable was less interoperable, and maybe it's something they can just not do for Firefox now.. but that isn't something I can confirm from just their minified code.

:masayuki, does this analysis give you any other clues, or should we just reach out to GMail and report this?

Comment 6

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I think that we can do nothing. So, could you contact Gmail developers? (Thank you very much tackling such complicated code!!)

Comment 7

[Dennis Schubert [:denschub]]

I sent Google an email.