Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should deleting cell's content on a table inside a contenteditable area imply the whole table has to be deleted ? #163

Closed
javifernandez opened this Issue Jun 9, 2017 · 34 comments

Comments

Projects
None yet
5 participants
@javifernandez
Copy link

javifernandez commented Jun 9, 2017

Let's consider this simple case:

<div id="editable" contenteditable="true">
    <table border="1"><tr><td>A</td><td></td></tr></table>
</div>

Place editing cursor after the "A" and press backspace, so the only cell in the table becomes empty.

Both WebKit/Safari and Blink/Chrome delete the whole table.
Firefox and IE/Edge just delete the cell's content but keep the empty table.

I couldn't find anything in the specs to address this situation and it looks like a clearly interoperability issue. I'm implementing a fix for WebKit and Blink to match the behavior of Firefox and IE/Edge, but I'd need to clarify if this is the expected behavior we really want.

@javifernandez javifernandez changed the title Should deleting cell's content on a table inside a contenteditable cell cause the whole table to be deleted ? Should deleting cell's content on a table inside a contenteditable area cause the whole table to be deleted ? Jun 9, 2017

@javifernandez javifernandez changed the title Should deleting cell's content on a table inside a contenteditable area cause the whole table to be deleted ? Should deleting cell's content on a table inside a contenteditable area implies the whole table to be deleted ? Jun 9, 2017

@johanneswilm

This comment has been minimized.

Copy link
Contributor

johanneswilm commented Jun 9, 2017

@javifernandez It would seem to me that the Firefox/Edge behavior is preferable as the user action doesn't indicate that the table should disappear.

@javifernandez

This comment has been minimized.

Copy link
Author

javifernandez commented Jun 9, 2017

@johanneswilm I agree.
I wonder if we should add something to the specs to clarify it, though. Otherwise, it complicates discussions with the different engines. Although enough support on one of another direction indeed helps.

@frivoal

This comment has been minimized.

Copy link

frivoal commented Jun 9, 2017

I agree on the preferred behavior.

The spec as it is has a detailed algorithm that's supposed to cover all situations. It is particularly intricate had hard to follow from a high level, and it is not clear to me that any browser is paying attention to what it says.

If browsers are indeed willing to follow that spec, then it is worth fixing and having detailed tests.

Otherwise, we need to find a different approach for specifying the things we do agree on.

Personally, I am not a fan of this kind of programming-in-english specifications, and would prefer stating the desired outcome than the way to get there, but at the same time, this is a particularly intricate case, so maybe it is justified. Either way, we need browser buy in on the idea of specifying.

Interop is desirable, so I hope we can agree that we want a spec.

@johanneswilm

This comment has been minimized.

Copy link
Contributor

johanneswilm commented Jun 9, 2017

Yeah, I was just about to say that we previously said we are not going to spend much time on this, as JS editors will override it anyway and browsers refuse to implement the entire spec. That being said, we also agreed to allowing minor, uncontroversial changes to the spec draft as some browser devs actually do consult these for sone things, even though there is a huge disclaimer there.
So I would say that unless someone is opposed to adding this, @javifernandez can send in a patch with the mentioned additions, and we'll just merge it.

@frivoal

This comment has been minimized.

Copy link

frivoal commented Jun 9, 2017

So I would say that unless someone is opposed to adding this, @javifernandez can send in a patch with the mentioned additions, and we'll just merge it.

Is the current state of the spec known to be good, and just needing this change if we agree on it, or do we first need to do an extensive review of the whole algo described in the spec to verify that what it says makes sense and (generally) matches implementations?

Are there tests for this?

@johanneswilm

This comment has been minimized.

Copy link
Contributor

johanneswilm commented Jun 9, 2017

The spec draft is not in a good shape and would require a few years of discussions to be fully implementable.
However, some browser people have in the past added small changes here and there and because they are only interested in one specific paragraph or sentence, they have felt this was useful for them. Tests existed a few years back.
Please note that this spec is not the focus of the editing taskforce, but we are still the right place to go to talk about this.

@johanneswilm

This comment has been minimized.

Copy link
Contributor

johanneswilm commented Jun 9, 2017

@frivoal and @javifernandez You have both seen the big disclaimer at the top of the spec [1], right?

This spec is incomplete and it is not expected that it will advance beyond draft status. Authors should not use most of these features directly, but instead use JavaScript editing libraries. The features described in this document are not implemented consistently or fully by user agents, and it is not expected that this will change in the foreseeable future. There is currently no alternative to some execCommand actions related to clipboard content and contentEditable=true is often used to draw the caret and move the caret in the block direction as well as a few minor subpoints. This spec is to mean to help implementations in standardizing these existing features. It is predicted that in the future both specs will be replaced by Content Editable and Input Events.

Of course, this could be removed or changed if the overall mood among browser makers changes.

[1] http://w3c.github.io/editing/contentEditableTrue.html

@gked

This comment has been minimized.

Copy link

gked commented Jun 9, 2017

I would like to propose another use case up for discussion. What would you expect to happen if we have an empty table and user presses Backspace while cursor is in the first column of the first row? I am thinking, for the sake of consistency with how lists are implemented, remove entire table. Thoughts?


@johanneswilm

This comment has been minimized.

Copy link
Contributor

johanneswilm commented Jun 9, 2017

@gked I can see several things that make sense. For example:

  1. Delete table (as you say). The user clearly intended to delete something, the cursor is in this table, not much information is lost anyway, so just remove it.

  2. Do nothing. It is not clear what the user wanted to do, and so it's better just to not do anything.

  3. Make a separation between deletion of simple and complex content. Simple content is text content content and the start and end of a paragraph. Complex content are non-editable elements, SVGs, images, tables, etc. . When the user is about to delete complex content, it may not always be apparent what will happen, and a lot could be lost if a gigantic table is being deleted. So in the case of complex content, if the selection is collapsed and the user indicates deletion, do not delete, but select the complex content in question. This behavior was specified in an earlier draft. So in this case, if we believe the user wanted to delete the (empty) table, select it instead of deleting it. Of course in this particular case the table can hardly be said to be complex content, but for consistency reasons, it would be good to treat all table deletion the same.

  4. Add an empty cell into a previous sibling table if there is one.

@javifernandez

This comment has been minimized.

Copy link
Author

javifernandez commented Jun 9, 2017

@johanneswilm

This comment has been minimized.

Copy link
Contributor

johanneswilm commented Jun 9, 2017

I'm perfectly aware of current state of the spec,
but I think that before changing the behavior of both browser some
discussion among the editing task force would be healthful.

Ok, good. then this makes sense.

@javifernandez

This comment has been minimized.

Copy link
Author

javifernandez commented Jun 9, 2017

@chaals

This comment has been minimized.

Copy link

chaals commented Jun 12, 2017

@gked wrote:

What would you expect to happen if we have an empty table and user presses Backspace while cursor is in the first column of the first row? I am thinking, for the sake of consistency with how lists are implemented, remove entire table. Thoughts?

If there is only one cell in the table I would expect the table to be deleted. If there is more than one cell, I am not sure what I expect, but I could easily get used to the idea that it deletes the table.

Certainly if I am in the second empty cell of a single-row table I would expect it to delete the cell and not the table - and in a multi-row empty table, to delete the column.

Table editing really is hard... :S

@javifernandez

This comment has been minimized.

Copy link
Author

javifernandez commented Jun 13, 2017

The execCommand spec states the following when specifying the behavior of "delete command":

https://w3c.github.io/editing/execCommand.html

Tables are a notable special case. If an entire table is contained in the range, it will be deleted. If it's anything less, only the contents of the cells will be deleted and the table structure will be left intact.

I think this can be applied when deleting content from the cursor/caret position. Hence, independently on the number of cells or which one the cursor is placed on, the command should only delete the cell's content.

I think that is agreed, at least most of browser either implement it that way or have bugs to do so, that hitting backspace after a table (in the same line) will select the whole table so next backspace hit will delete the whole table. I think that behavior is clearer and more explicit of what the user intended to do.

Deleting the table when the user hit backspace on the last character of the first cell would lead to an unexpected behavior. The user might have hit backspace continuously or an excessive number of times, just to be sure the whole cell's content is deleted, but didn't want actually to delete the table itself.

Deleting the table when hitting backspace on the last character in the second cell would make even less sense, IMHO. We can agree on moving the cursor to the previous cell, and eventually, if we want, delete the table when reaching the first cell if the table gets empty.

@chaals

This comment has been minimized.

Copy link

chaals commented Jun 13, 2017

@javifernandez wrote:

Deleting the table when the user hit backspace on the last character of the first cell would lead to an unexpected behavior. The user might have hit backspace continuously or an excessive number of times, just to be sure the whole cell's content is deleted, but didn't want actually to delete the table itself.

Deleting the table when hitting backspace on the last character in the second cell would make even less sense, IMHO. We can agree on moving the cursor to the previous cell, and eventually, if we want, delete the table when reaching the first cell if the table gets empty

Yeah, except this still means when the user hits backspace 19 times instead of the necessary 17 their table suddenly vanished.

I suspect that reality-testing will show that we can't save us from that and providing an undo that separates "delete cell content" from "delete the table structure" is about as good as it gets. So, let's see some reality testing :)

@frivoal

This comment has been minimized.

Copy link

frivoal commented Jun 20, 2017

@johanneswilm Even if we don't go as far as fixing the spec, given how much work it would be to even make sure of the general sanity of the section we'd consider amending, would it be possible to try a call for consensus on this specific case? Since we have an interop problem, and someone willing to write patches, if we manage to get in agreement over what's supposed to happen, we can make progress, spec or no spec. Can you ping the relevant people (or use an upcoming teleconf of f2f meeting if any such thing is scheduled)?

@johanneswilm

This comment has been minimized.

Copy link
Contributor

johanneswilm commented Jun 20, 2017

@frivoal Yes, bringing it up at the next teleconference was what I had planned anyway. There may not be any discussion if everyone is in agreement on one particular issue. That's how we have been handling these cases so far.

@johanneswilm

This comment has been minimized.

Copy link
Contributor

johanneswilm commented Jun 20, 2017

And then we have added specific wording to the spec draft. I think that is in line with everything else we have been doing. Let's just wait a little longer here to see if there is disagreement here first.

@javifernandez javifernandez changed the title Should deleting cell's content on a table inside a contenteditable area implies the whole table to be deleted ? Should deleting cell's content on a table inside a contenteditable area imply the whole table to be deleted ? Jun 30, 2017

@javifernandez javifernandez changed the title Should deleting cell's content on a table inside a contenteditable area imply the whole table to be deleted ? Should deleting cell's content on a table inside a contenteditable area imply the whole table has to be deleted ? Jun 30, 2017

@javifernandez

This comment has been minimized.

Copy link
Author

javifernandez commented May 9, 2018

Ok, I'm working again on this issue, trying to get some kind of consensus here (even if that doesn't imply a specific statement in the spec). From #163 (comment) I've understood that there were some changes in the spec regarding this issue; could anybody please tell me which ones ?

Anyway, I'll describe here current behavior using four of the main browsers with a simple case:

<div contenteditable>
  <div>
    before
    <table border=1>
      <tbody>
        <tr><td>1</td><td>2</td><td>3</td></tr>
      </tbody>
    </table>
    after
  </div>
</div>

Case 1: Selecting content from the first cell to the last one

Firefox 59Edge 16WebKit Preview and Chrome 68

Case 2: Selecting content from the text above the table to its last cell

Firefox 59Edge 16WebKit Preview and Chrome 68

Case 3: Selecting content from the start of the text above the table to the start of the text below

Firefox 59Edge 16WebKit Preview and Chrome 68

Case 4: Selecting content from the end of the text above the table to the end of the text below

Firefox 59Edge 16WebKit Preview and Chrome 68
@johanneswilm

This comment has been minimized.

Copy link
Contributor

johanneswilm commented May 9, 2018

@javierfernandez: I don't think anything was changed due to this issue. Your last comment seems to refer to selection without DOM changes, correct? In that case it should be dealt with in the selection API and similar, not editing. And if I recall correctly, there are some intentional OS and UA differences that mean that selections willnot work the same everywhere.

@javifernandez

This comment has been minimized.

Copy link
Author

javifernandez commented May 9, 2018

Umm, there is no issue with selection here. Browsers are not interoperable because they took different decisions about whether to delete the whole table or just the content when it's all selected.

@johanneswilm

This comment has been minimized.

Copy link
Contributor

johanneswilm commented May 9, 2018

Umm, there is no issue with selection here.

@javifernandez Sorry, I was confused by the titles of the cases. So basically you are giving examples of how selection happened and then what happens if the user hits del or backspace, right? Does it make any difference how you delete the content? What happens if you replace the content with something else (such as hitting a letter key when the relevant content is selected)?

Is there some preference as what you think should happen?

My personal favorites would be:

Case 1: Webkit/Chrome (but is there no caret at all?)
Case 2: Webkit/Chrome (but confused why the caret is at the beginning of the second line and not the first line)
Case 3: Firefox/Edge
Case 4: Firefox/Edge/Webkit/Chrome

@javifernandez

This comment has been minimized.

Copy link
Author

javifernandez commented May 10, 2018

I was confused by the titles of the cases. So basically you are giving examples of how selection happened and then what happens if the user hits del or backspace, right?

Sorry about the confusion that some of the examples may have created; I'll try to provide Web Platform Tests to be more explicit about each case and the expected behavior. Yes, my intention was to show the different behavior when hitting backspace on each selection. I'm specially interested on case1, though, where I tend to think Firefox and Edge have better (more conservative) behavior.

My argument in favor of Firefox's and Edge's behavior in Case 1 is that deleting the table structure when the last cell's content is deleted is too aggressive. Consider the case of an user deleting content cell by cell, just to replace it with new content, and once it reaches the last cell the whole table is deleted.

The rest of the cases show a way where use consciously selects the whole table so that i indicates explicitly the desire of delete it (including the table's structure).

I think some Browsers, (don't recall now but I can do some test to figure it out) selects the table structure after hitting backspace after deleting the last non-empty cell. I think that allows the user to avoid accidentally deleting the table structure.

@johanneswilm

This comment has been minimized.

Copy link
Contributor

johanneswilm commented May 10, 2018

Consider the case of an user deleting content cell by cell, just to replace it with new content, and once it reaches the last cell the whole table is deleted.

Ok, but that seems like a slightly different case, right? In the case you showed above, the user was selected all contents of the table in one operation and then hits delete/backspace, the entire thing is gone. If the user instead selected the contents of individual cells and deletes them individually (before refilling), the same is not happening.

The reason I would go with the Chrome/Webkit behavior is that it's not really clear to the user whether she/he has selected the table contents or the table itself (no visual difference as far as I can tell), and in most cases (my guess) they will want to have selected the table rather than the table contents when deleting. Also, without the extra controls that only Firefox automatically adds to tables, there is no good way of deleting the entire table. Is there?

I can see this can people having preferences of either type. It probably depends a lot on how tables are used in the given JS editor and what purpose they have there. In the end the JS editor will be deciding how to handle this and whether it needs to add some extra styling to the table if the entire table is selected to make the distinction clearer to the end user.

So I think maybe the question of what should happen by default is less important as that the same happens in all browsers so that JS editor programmers have an easier time building their tools. So for example, that means getting rid of those extra default table controls in Firefox (as is happening alread). And maybe -- if this is not possible already without JavaScript -- it would be an idea to see if there is some way to distinguish visiually between selecting all cells of a table and selecting the entire table.

@johanneswilm

This comment has been minimized.

Copy link
Contributor

johanneswilm commented May 10, 2018

Btw, I didn't try all your tests, but in Firefox 59 on Linux, in case 2, I get different results. And the results also differ between using backspace and delete in that case.

In case 4, I just now realize that the deletion is eating an extra space backward. It should probably say "before ", but the result is "before". This extra space is there initially, then disappears and doesn't seem to come back. If one tries to type a single letter ("x") at the end of it "before |" it turns into "beforex". It is not present on other browsers.

Another test that you did not include -- select from the beginning of the first table cell to the end of "after" fails because it refuses to select more than the table contents. And even that it does rather badly -- if I accidentally move the mouse a bit downward during the selection, the selection goes no further, even if I move the mouse back up to try to select the remaining table cells.

These sort of selection issues are more problematic because they force JS editors to write weird work-arounds to get their editors to work properly, or write their own selection system. I think we have higher chances of getting the built-in selections good enough where most JS editors can rely on them than getting full agreement on all default editing operations.

@javifernandez

This comment has been minimized.

Copy link
Author

javifernandez commented May 11, 2018

Ok, but that seems like a slightly different case, right? In the case you showed above, the user was selected all contents of the table in one operation and then hits delete/backspace, the entire thing is gone. If the user instead selected the contents of individual cells and deletes them individually (before refilling), the same is not happening.

Yes, it's a different case indeed. I was more interested on the behavior of uses cases that doesn't involve selection. I used selection to illustrate with pictures the different use case (table content vs table structure), I'm sorry this created sort of confusion. As I said, I'll sent a PR with some test so that the use case and expected behavior are clearer.

Btw, I didn't try all your tests, but in Firefox 59 on Linux, in case 2, I get different results. And the results also differ between using backspace and delete in that case.

I'm using Firefox 59 on Linux, what are those different results you're getting ? I agree that behavior is different when using backspace or delete.

About the extra space, I see it in Firefox and Edge, but not in Chrome. I think it's related to the indentation of the html, but not related at all with this issue.

Another test that you did not include -- select from the beginning of the first table cell to the end of "after" fails because it refuses to select more than the table contents. And even that it does rather badly -- if I accidentally move the mouse a bit downward during the selection, the selection goes no further, even if I move the mouse back up to try to select the remaining table cells.

Yes, I noticed such behavior in both, Firefox and Edge. I wonder if that's intentional, but I'd say it is. In any case, another interoperability issue with Chrome and Safari. Anyway, I didn't want to focus so much on selection in this issue. As I said, my main concern here is how we should handle either backspace or delete (should both have the same behavior ?) and whether or not delete the table structure.

@johanneswilm

This comment has been minimized.

Copy link
Contributor

johanneswilm commented May 11, 2018

Yes, it's a different case indeed.

I think we are talking at cross purposes here. I meant that the these two use cases you describe are not the same thing:

  1. Consider the case of an user deleting content cell by cell, just to replace it with new content, and once it reaches the last cell the whole table is deleted.

and

  1. the user selects all contents of the table in one operation and then hits delete/backspace

The test you did above seems to be about 2 whereas in the text you seem to justify it with 1. If the user is indeed doing what you describe in 1, deleting the content of each cell separately, then the table is not deleted, as it is in case 2.

I was more interested on the behavior of uses cases that doesn't involve selection.

Ok, but all the usecases presented here involve deletion of selected content, right? So if you are thinking about usecases that don't invovle selected content, maybe you could present those as well?

@johanneswilm

This comment has been minimized.

Copy link
Contributor

johanneswilm commented May 11, 2018

I'm using Firefox 59 on Linux, what are those different results you're getting ? I agree that behavior is different when using backspace or delete.

Backspace:

firefox59_case2_backspace

Delete:

firefox59_case2_delete

@javifernandez

This comment has been minimized.

Copy link
Author

javifernandez commented May 11, 2018

Ok, but all the usecases presented here involve deletion of selected content, right?

Yes, they are all selection based. It's debatable in any case whether the table structure should be removed when deleting its content so that all the cells become empty.

So if you are thinking about usecases that don't invovle selected content, maybe you could present those as well?

Let's consider this case:

<div contenteditable>
    <table border=1>
      <tbody>
        <tr><td>A</td></tr>
      </tbody>
    </table>
</div>

Case1: Place caret after the letter "A" and hitting the backspace key

  • Chrome and Safari: The table structure gets deleted
  • Firefox and Edge: The table cell gets empty, but the table structure isn't deleted.

Case2: Place caret before the letter "A" and hitting the delete key

  • Chrome and Safari: The table structure gets deleted
  • Firefox and Edge: The table cell gets empty, but the table structure isn't deleted.
@johanneswilm

This comment has been minimized.

Copy link
Contributor

johanneswilm commented May 11, 2018

Granted, the Chrome/Safari is questionable. But this only applies to single cell tables, right?

If there is a second cell, even an empty one, it does not happen:

<div contenteditable>
    <table border=1>
      <tbody>
        <tr><td>A</td><td></td></tr>
      </tbody>
    </table>
</div>

So the question is then more: Why is there a table with a single cell? What is the the website author trying to achieve with that?

@javifernandez

This comment has been minimized.

Copy link
Author

javifernandez commented May 14, 2018

So the question is then more: Why is there a table with a single cell? What is the the website author trying to achieve with that?

Well, since this is a contenteditable area is up to the users to introduce, using rich text editors like quilljs [1], the content they consider more appropriated to their needs; it's also worth considering that Microsoft Word doesn't delete the table in this case. In your comment #163 (comment) you acknowledged this would be your preferred behavior, matching also what Firefox and Edge do as well.

Finally, I'd like to introduce the idea that this single cell table may be an intermediate state of a more complex table structure that the user has in mind. Admitting that it may be unlikely that an user may follow this patch to achieve its final editing work, it's undeniable that deleting the whole table in this case may lead to a frustrating text editing experience.

[1] https://quilljs.com/

@johanneswilm

This comment has been minimized.

Copy link
Contributor

johanneswilm commented May 14, 2018

As for #163 (comment), that seems to have been a multicell table, right?

I have been thinking about this over the last few days. I think treating one-cell single-character tables differently than other tables must at some point of time having had to do with such tables being used for styling of letters or words. Or someone imagined that it could be used for that, or somehow those kinds of tables were thrown into the same category as elements that are typically used for styling...

At any rate, I cannot think of a good example where it would make sense to use a table for the purpose of styling as of 2018. And if we accept that JS editors will be either be executing editing operations entirely by themselves or do at least take over a great part of these editing operations... the one thing that is not very welcome by those writing these editors is unpredictable or surprising behavior on the part of browsers. Treating single cell tables differently than other tables is an example of really surprising behavior in my view.

So yes, although I really cannot see the purpose of single-cell tables, I agree with you, in those cases where they do exist, browsers should treat them like any other table.

As for behavior when selecting the entire table and deleting it vs selecting all contents of a table and then deleting, I feel there needs to be some type of visual distinction between the two types of selections. If there is no distinction, then it should behave according to what the most common case is, which I would guess to be to delete the entire table.

@javifernandez

This comment has been minimized.

Copy link
Author

javifernandez commented May 14, 2018

As for #163 (comment), that seems to have been a multicell table, right?
That's true, sorry about the confusion; I think the issue was reproducible with a multicell case too (perhaps it was at some point), but it's not the case anymore; the issue only happens with single-cell tables, indeed.

Anyway, I think we've got an agreement, so I'll try to discuss with the webkit and blink engineers about the possibility to follow Firefox and Edge behavior, which in fact would mean to solve this interoperability issue.

Thanks.

@javifernandez

This comment has been minimized.

Copy link
Author

javifernandez commented May 21, 2018

I think we can close this issue now. If anybody disagrees with the resolution, we can reopen it to continue the discussion.

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Jul 10, 2018

Don't extend selection for special elements on caret based deletes
We should not extend selection looking for special elements if the
delete operation has been triggered by a caret based selection.

This change is based on a recent [1] resolution of the Editing TF,
which acknowledges that behavior of single-cell tables must be the
same that multi-cell tables and even if the last character is
deleted, we should not delete the whole table structure.

A different case would be when the user actively selects the whole
content of a table; in this case, as we do in multi-cell tables,
the structure of single-cell tables should be deleted together
with the content.

[1] w3c/editing#163

Bug: 731320
Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_layout_ng
Change-Id: I8c3e4efcc63410bf30b4889a715d92e9dda8189b

hubot pushed a commit to WebKit/webkit that referenced this issue Jul 17, 2018

jfernandez@igalia.com
Delete content of a single cell table should not delete the whole table
https://bugs.webkit.org/show_bug.cgi?id=173117

Reviewed by Ryosuke Niwa.

Source/WebCore:

We should not extend selection looking for special elements if the
delete operation has been triggered by a caret based selection.

This change is based on a recent [1] resolution of the Editing TF,
which acknowledges that behavior of single-cell tables must be the
same that multi-cell tables and even if the last character is
deleted, we should not delete the whole table structure.

A different case would be when the user actively selects the whole
content of a table; in this case, as we do in multi-cell tables,
the structure of single-cell tables should be deleted together
with the content.

[1] w3c/editing#163

Tests: editing/deleting/backspace-delete-last-char-in-table.html
       editing/deleting/forward-delete-last-char-in-table.html
       editing/deleting/select-and-delete-last-char-in-table.html

* editing/TypingCommand.cpp:
(WebCore::TypingCommand::deleteKeyPressed):
(WebCore::TypingCommand::forwardDeleteKeyPressed):

LayoutTests:

Tests to verify that single-cell tables are not deleted when their
last character is deleted, unless it was previously selected by
the user.

Changes two expected files to adapt them to the new logic.

* LayoutTests/editing/deleting/deleting-relative-positioned-special-element-expected.txt: The paragraph is not deleted, even if it's empty. The paragraphs above are not merged, which was the goal of the test.
* editing/deleting/delete-last-char-in-table-expected.txt: The table is not removed, even if it's empty. The formatted elements are deleted, which was the goal of the test.
* editing/deleting/backspace-delete-last-char-in-table-expected.txt: Added.
* editing/deleting/backspace-delete-last-char-in-table.html: Added.
* editing/deleting/forward-delete-last-char-in-table-expected.txt: Added.
* editing/deleting/forward-delete-last-char-in-table.html: Added.
* editing/deleting/select-and-delete-last-char-in-table-expected.txt: Added.
* editing/deleting/select-and-delete-last-char-in-table.html: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@233885 268f45cc-cd09-0410-ab3c-d52691b4dbfc

aarongable pushed a commit to chromium/chromium that referenced this issue Jul 17, 2018

Don't extend selection for special elements on caret based deletes
We should not extend selection looking for special elements if the
delete operation has been triggered by a caret based selection.

This change is based on a recent [1] resolution of the Editing TF,
which acknowledges that behavior of single-cell tables must be the
same that multi-cell tables and even if the last character is
deleted, we should not delete the whole table structure.

A different case would be when the user actively selects the whole
content of a table; in this case, as we do in multi-cell tables,
the structure of single-cell tables should be deleted together
with the content.

[1] w3c/editing#163

Bug: 731320
Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_layout_ng
Change-Id: I8c3e4efcc63410bf30b4889a715d92e9dda8189b
Reviewed-on: https://chromium-review.googlesource.com/1126255
Commit-Queue: Javier Fernandez <jfernandez@igalia.com>
Reviewed-by: Yoshifumi Inoue <yosin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#575591}

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Jul 17, 2018

Don't extend selection for special elements on caret based deletes
We should not extend selection looking for special elements if the
delete operation has been triggered by a caret based selection.

This change is based on a recent [1] resolution of the Editing TF,
which acknowledges that behavior of single-cell tables must be the
same that multi-cell tables and even if the last character is
deleted, we should not delete the whole table structure.

A different case would be when the user actively selects the whole
content of a table; in this case, as we do in multi-cell tables,
the structure of single-cell tables should be deleted together
with the content.

[1] w3c/editing#163

Bug: 731320
Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_layout_ng
Change-Id: I8c3e4efcc63410bf30b4889a715d92e9dda8189b
Reviewed-on: https://chromium-review.googlesource.com/1126255
Commit-Queue: Javier Fernandez <jfernandez@igalia.com>
Reviewed-by: Yoshifumi Inoue <yosin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#575591}

chromium-wpt-export-bot added a commit to web-platform-tests/wpt that referenced this issue Jul 17, 2018

Don't extend selection for special elements on caret based deletes
We should not extend selection looking for special elements if the
delete operation has been triggered by a caret based selection.

This change is based on a recent [1] resolution of the Editing TF,
which acknowledges that behavior of single-cell tables must be the
same that multi-cell tables and even if the last character is
deleted, we should not delete the whole table structure.

A different case would be when the user actively selects the whole
content of a table; in this case, as we do in multi-cell tables,
the structure of single-cell tables should be deleted together
with the content.

[1] w3c/editing#163

Bug: 731320
Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_layout_ng
Change-Id: I8c3e4efcc63410bf30b4889a715d92e9dda8189b
Reviewed-on: https://chromium-review.googlesource.com/1126255
Commit-Queue: Javier Fernandez <jfernandez@igalia.com>
Reviewed-by: Yoshifumi Inoue <yosin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#575591}

moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Jul 29, 2018

Bug 1473431 [wpt PR 11791] - Don't extend selection for special eleme…
…nts on caret based deletes, a=testonly

Automatic update from web-platform-testsDon't extend selection for special elements on caret based deletes

We should not extend selection looking for special elements if the
delete operation has been triggered by a caret based selection.

This change is based on a recent [1] resolution of the Editing TF,
which acknowledges that behavior of single-cell tables must be the
same that multi-cell tables and even if the last character is
deleted, we should not delete the whole table structure.

A different case would be when the user actively selects the whole
content of a table; in this case, as we do in multi-cell tables,
the structure of single-cell tables should be deleted together
with the content.

[1] w3c/editing#163

Bug: 731320
Cq-Include-Trybots: luci.chromium.try​:linux_layout_tests_layout_ng
Change-Id: I8c3e4efcc63410bf30b4889a715d92e9dda8189b
Reviewed-on: https://chromium-review.googlesource.com/1126255
Commit-Queue: Javier Fernandez <jfernandez@igalia.com>
Reviewed-by: Yoshifumi Inoue <yosin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#575591}

--

wpt-commits: d409e3882d9322655b6113d1e1688d657eec2b3d
wpt-pr: 11791

jankeromnes pushed a commit to jankeromnes/gecko that referenced this issue Jul 30, 2018

Bug 1473431 [wpt PR 11791] - Don't extend selection for special eleme…
…nts on caret based deletes, a=testonly

Automatic update from web-platform-testsDon't extend selection for special elements on caret based deletes

We should not extend selection looking for special elements if the
delete operation has been triggered by a caret based selection.

This change is based on a recent [1] resolution of the Editing TF,
which acknowledges that behavior of single-cell tables must be the
same that multi-cell tables and even if the last character is
deleted, we should not delete the whole table structure.

A different case would be when the user actively selects the whole
content of a table; in this case, as we do in multi-cell tables,
the structure of single-cell tables should be deleted together
with the content.

[1] w3c/editing#163

Bug: 731320
Cq-Include-Trybots: luci.chromium.try​:linux_layout_tests_layout_ng
Change-Id: I8c3e4efcc63410bf30b4889a715d92e9dda8189b
Reviewed-on: https://chromium-review.googlesource.com/1126255
Commit-Queue: Javier Fernandez <jfernandez@igalia.com>
Reviewed-by: Yoshifumi Inoue <yosin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#575591}

--

wpt-commits: d409e3882d9322655b6113d1e1688d657eec2b3d
wpt-pr: 11791
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.