Should deleting cell's content on a table inside a contenteditable area imply the whole table has to be deleted ? #163
Comments
javifernandez
changed the title
javifernandez
changed the title
|
@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. |
|
@johanneswilm I agree. |
|
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. |
|
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. |
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? |
|
The spec draft is not in a good shape and would require a few years of discussions to be fully implementable. |
|
@frivoal and @javifernandez You have both seen the big disclaimer at the top of the spec [1], right?
Of course, this could be removed or changed if the overall mood among browser makers changes. |
|
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? |
|
@gked I can see several things that make sense. For example:
|
|
Hi,
On 06/09/2017 12:22 PM, Johannes Wilm wrote:
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.
I'm working on several interoperability issues shared by WebKit/Safari
and Chromium/Blink. 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. It'd
will help eventually in the technical discussions to justify the change.
|
Ok, good. then this makes sense. |
|
Hi,
On 06/09/2017 02:17 PM, Johannes Wilm wrote:
@frivoal <https://github.com/frivoal> and @javifernandez
<https://github.com/javifernandez> You have both seen the big disclaimer
at the top of the spec [1], right?
Yes, I'm also aware of the mentioned disclaimer.
Of course, this could be removed or changed if the overall mood among
browser makers changes.
As mentioned before, this would require several years of discussion and
analysis, so I'm not sure it should prevent fixing bugs and at the same time
improve browser interoperability.
This issue, and others I've just created, are just intended to gather
feedback
on the preferred behavior of specific use cases and the rationale behind the
one implemented by the different browsers. If it's possible to change the
spec, then it'd be the ideal situation, but I understand how complex is
that
goal considering its current state.
|
|
@gked wrote:
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 |
|
The execCommand spec states the following when specifying the behavior of "delete command": https://w3c.github.io/editing/execCommand.html
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. |
|
@javifernandez wrote:
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 :) |
|
@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)? |
|
@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. |
|
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
changed the title
javifernandez
changed the title
|
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: Case 1: Selecting content from the first cell to the last one
Case 2: Selecting content from the text above the table to its last cell
Case 3: Selecting content from the start of the text above the table to the start of the text below
Case 4: Selecting content from the end of the text above the table to the end of the text below
|
||||||||||||||||||||||||||||||||||||||||||||||||
|
@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. |
|
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. |
@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?) |
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. |
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. |
|
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. |
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.
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.
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. |
I think we are talking at cross purposes here. I meant that the these two use cases you describe are not the same thing:
and
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.
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? |
Backspace:
Delete:
|
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.
Let's consider this case: Case1: Place caret after the letter "A" and hitting the backspace key
Case2: Place caret before the letter "A" and hitting the delete key
|
|
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: 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. |
|
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. |
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. |
|
I think we can close this issue now. If anybody disagrees with the resolution, we can reopen it to continue the discussion. |
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
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
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}
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}
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}
…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
…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
…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 <jfernandezigalia.com> Reviewed-by: Yoshifumi Inoue <yosinchromium.org> Cr-Commit-Position: refs/heads/master{#575591} -- wpt-commits: d409e3882d9322655b6113d1e1688d657eec2b3d wpt-pr: 11791 UltraBlame original commit: 675aa36a69e5fb5ffb76ab9543e31e59c6ff8783
…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 <jfernandezigalia.com> Reviewed-by: Yoshifumi Inoue <yosinchromium.org> Cr-Commit-Position: refs/heads/master{#575591} -- wpt-commits: d409e3882d9322655b6113d1e1688d657eec2b3d wpt-pr: 11791 UltraBlame original commit: 675aa36a69e5fb5ffb76ab9543e31e59c6ff8783
…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 <jfernandezigalia.com> Reviewed-by: Yoshifumi Inoue <yosinchromium.org> Cr-Commit-Position: refs/heads/master{#575591} -- wpt-commits: d409e3882d9322655b6113d1e1688d657eec2b3d wpt-pr: 11791 UltraBlame original commit: 675aa36a69e5fb5ffb76ab9543e31e59c6ff8783
Let's consider this simple case:
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.
The text was updated successfully, but these errors were encountered: