Bug 209605

Summary: [GTK] Deleting an empty line can delete -webkit-user-select: none content inside a blockout succeeding the line
Product: WebKit Reporter: Milan Crha <mcrha>
Component: HTML EditingAssignee: Nobody <webkit-unassigned>
Status: NEW ---    
Severity: Normal CC: megan_gardner, rniwa, webkit-bug-importer, wenson_hsieh
Priority: P2 Keywords: InRadar
Version: Other   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
a.html (good)
none
a.html (bad) none

Description Milan Crha 2020-03-26 10:14:01 PDT
Created attachment 394620 [details]
a.html (good)

It depends what the next sibling element contains when a Delete key is pressed in an empty DIV, while I'd expect the same behaviour (the empty paragraph being removed) regardless of the next element content.

a) Open the attached a.html file in a MiniBrowser like this:

     $ MiniBrowser --editor-mode /tmp/a.html

   It opens with this content:

      line 0

      > line 1
      > line 2
      > line 3

   where the '>' are orange.

b) Place the cursor on the second line, aka on the empty line below the line with the 'line 0' text.
c) press Delete key

What happens:

The text is changed to:

      line 0
      line 1
      > line 2
      > line 3

What is expected:

Only the empty line is removed, thus it might look like this:

      line 0
      > line 1
      > line 2
      > line 3

Note: It seems to be related to -webkit-user-select: none; style property of .-x-evo-quoted (see the a.html file). When I change the ".-x-evo-quoted" in the <style> to something else, thus it doesn't match anything in the HTML body, like to .zzz-x-evo-quoted, then the steps behave as expected.

I see this behaviour with WebKitGTK+ at r258908.
Comment 1 Radar WebKit Bug Importer 2020-03-26 11:46:41 PDT
<rdar://problem/60929041>
Comment 2 Milan Crha 2020-03-26 23:56:32 PDT
Created attachment 394709 [details]
a.html (bad)

(In reply to Milan Crha from comment #0)
> When I change the ".-x-evo-quoted" in the <style> to something else, thus it
> doesn't match anything in the HTML body, like to .zzz-x-evo-quoted, then
> the steps behave as expected.

Just a comment about this. I've been testing the change before submitting the bug and, of course, I did not remove the 'zzz' from the name before sumbit, thus the above attached a.html works properly.

I'm attaching also the "bad" version, for simplicity. The only difference is the "zzz", as mentioned above.
Comment 3 Ryosuke Niwa 2020-03-27 23:11:22 PDT
Oh, I misunderstood the problem. This isn't even a list; just a blockquote. FWIW, this doesn't seem to impact macOS.