Selection#getSelectedBlocks() should not return the last block if its content is not selected

[Reinmar]

There's a very popular use case in which the selection ends in a block which the user didn't want to select. What's more, the user doesn't see that that additional block was selected too. This results in a confusion when the user tries to change the format (e.g. apply a heading or a list) of the selected blocks.

Example:

<paragrap>Foo</paragraph>
<paragrap>Bar</paragraph>
<paragrap>Baz</paragraph>

If the user triple clicks on the second paragraph the browser will render this (something which looks like just the "Bar" paragraph selected):

However, changing the format, will also change the format of the following "Baz" block:

The reason why heading is applied to two blocks now is that the selection which browser creates on tripleclick looks like this:

<paragrap>Foo</paragraph>
<paragrap>[Bar</paragraph>
<paragrap>]Baz</paragraph>

So it ends in the 3rd paragraph. In Chrome and Firefox this is pretty much indistinguishable from a selection which would span only over "Bar": <paragraph>[Bar]</paragraph>. Safari is smarter here and renders such a selection:

Still, the user is not expecting that the style will affect also the last line as it doesn't seem to be selected at all in neither browser.

What's more – such a selection can not only be created by tripleclicks, but also Shift+arrow (usually, a non-confusing case) or mouse (a confusing case too).

Solution

We can't try to fix the selection (e.g. trim it) in any way as such selections are totally valid and the user must be able to create them (e.g. when changing the selection using Shift+arrow). This means that we can't convert the selection differently from the view to the model or in any way change its model representation. It's just as it is.

The only thing we can do is to not return the last block from "format" oriented methods like Selection#getSelectedBlocks().

This is what Google Docs, despite its completely custom rendering mechanism, do as well as I explained in this comment so we should be really fine.