Shift+arrow not working as expected in blockquote

[ellatrix]

Issue Overview

When using shift and arrow down in a blockquote, the caret moves to the citation instead of selecting the next.

Steps to Reproduce (for bugs)

1. Put the caret in a blockquote.
2. Press shift+arrow down.
3. Observe the caret jumping to the citation.

Expected Behavior

I expect multi-selection with the next block.

Related Issues and/or PRs

#3038.

[ephox-mogran]

I thought this was desired behaviour. Ideally, it should select from the quote to the citation ... but it can't until we sort out the range spanning two content editables. If you shift+down from the citation or shift+up from the quote, it selects multiple blocks ... you need to be at the editable at the appropriate edge. This was the intention... to mimic natural selection across paragraphs as much as possible. I can change it if desired, but this case (block quote) was specifically designed to work this way in the PR. Does that make sense?

[ellatrix]

Ah, I'm going from #2990 (comment) :) Okay, maybe not so much a bug, but layer to add.

[ephox-mogran]

So, what is the desired behaviour here? Should it select all the contents of the block, but not go into multi-select mode? Is that the idea?

At the moment, you can't go into multi-select mode if the start and end block are the same, so I assume you just want everything within the block to be selected (if it's possible ... it will depend on whether or not selecting from 0 to childNodes.length inside the outer container is considered spanning from two content editable regions).

@iseulde @jasmussen @mcsf

[ephox-mogran]

The other problem is that if it selects all the contents in the block, but doesn't go into multi-selection mode, it will looks like it's editable, but it won't be. Keystrokes etc. will have unexpected behaviour. Maybe we should just allow single block multi-selections? And if so, would we need to allow it with the mouse also?

[ephox-mogran]

So I've played with this briefly. If we want to select all of the contents, without selecting the block (in a multi-block selection consisting of one block), then we need to put zero width cursors above and below the editable sections inside the blockquote. Otherwise, Chrome will normalise the selection range down to the editables, and the selection won't be able to span two editables. However, if we do add these zero width cursors, then typing does nothing even though it looks like it should, because your selection it outside anything that is editable. To keep the behaviour that you want, the only way I can see to do it is to allow a multiselection that has the same start and end block. However, that it not possible with the mouse, and is currently disabled with the keyboard. Do you want to add that capability?

[jasmussen]

So, what is the desired behaviour here? Should it select all the contents of the block, but not go into multi-select mode? Is that the idea?
At the moment, you can't go into multi-select mode if the start and end block are the same, so I assume you just want everything within the block to be selected (if it's possible ... it will depend on whether or not selecting from 0 to childNodes.length inside the outer container is considered spanning from two content editable regions).

Two things;

First off, it's probably okay to let the recently merged behavior live in 1.6 for at least a week, until 1.7, so we can get a feel for it. It's not ultra urgent to fix this issue, in other words. We have something that works pretty well, and a fix to this bug I would consider to be partially in the "enhancement" camp.

Secondly — the behavior we right now think is desirable is exactly what Ella refers to in this comment:

If you start the selection inside a complex block, you select the block first

Let's say you have a quote with a citation, and you set the caret inside the quote, select until the end of the quote, and press shift down (towards the citation) — then you select the whole quote block first, and then you select successive blocks if you continue.

I'm not saying the above is necessarily easy to do, but it feels like the right approach. What do you think?

[jeffpaul]

This ticket was mentioned in Slack in #core-editor by jeffpaul. View the logs.

[designsimply]

This looks fixed! (13s)