Issue 60612

Is the same root cause as in issue 45348.

*** This issue has been marked as a duplicate of 45348 ***

Closing duplicate.

This issue 60612 is about something else than issue 45890 but both are marked as
a duplicate of one issue.
Strange...

Yes I have also felt this often when a issue marked "duplicate" is actually not
duplicate; but in fact is a RELATED bug, with a different set of symptoms. 

The root cause is the same; so when that is addressed, both issues would get
solved at once. But that is no reason to close one of them in advance!

I think it is a workaround for a weakness of the process AND tool (bugzilla).

Bugzilla has no default provision to mark a "variant". Just like the "depends
on" or "blocks", it should have another field for "variants" (issues that are
closely related, but show different symptoms). All variants should stay open
till the root cause is addressed, and then they should be closed together.

BTW I have often wondered if developers actually look at those "duplicates"
which actually would tell something more??

Anyway, when one of my issues are marked as duplicate, I simply visit the
"original" and put my point there. But most of the users would not do that. And
the loss is to OOo!

Is there a seperate section to raise such system/tool-related issues?

After reflecting on this issue I think we better open this issue!

MRU i think such "POSSIBLE variants of existing issues" could be marked as
dependent issues. (For example, show this issue as dependent on the original.)

If that is done, the advantage is that a separate verification will be needed to
close this issue. 

So, just in case they ARE different, this issue will stay open unless specific
action is taken to close it separately.

But if you are bound by "policy", I'll understand, of course! :)

Thanks.

We can hold this as an independant issue. But I do not how, it should be
technically solved, to distinct between text selection and cell selection mode.
If you have a textselection mode, you will not run anymore into cell selection
mode as described.
So you won't need to revert a cell selection back...
So what is your opinion about this?

While persuing this, I found meywer's comments in other issues. In fact, he has
found the real original (issue 58477). In fact, even the issue 45438 sstarted in
the same direction, but the discussion in it has veered towards "Crossing of
cell borders"; so technically it is a different issue. (I never attempted to
select text across a cell's border into the neighboring cell.)

But other issues describe exactly what I wanted to say. Since those issues were
raised before this one, and this issue can indeed be closed.

But there are two issues here: One for selection across several cells; and the
other selection within the cell.

This is what I wanted to explain to you...
If you start selecting text in a cell using the Shift-cursor keys and you reach
the end of the cell content, then there are two possibilities:
- the whole cell is selected /what OO currently does)
- the selection could continue to the text of the next cell (which than could be
easily reverted by shift-cursor-left back to the cell you started).

This is why I am the opinion that the issue are not just related but even the same.

Let me get this right:

Speaking specifically of tables, We have the following modes:
> a text selection mode. 
> a row selection mode
> a column selection mode

We have specific methods to start each. (e.g. hovering mouse just ABOVE the
table starts column-select mode; and just on the LEFT starts a row-select mode)

But do we also have a "cell-selection" mode that interferes with the "text
selection" mode? 

If yes, can't we keep them separate (e.g. by pressing a modifier key)? In that
case, Writer will let the user select text across different cells, without
switching over to cell-select mode.

Similar to issue 45348, a possibility is desired, when a selection of text in a
table reches end of cell content and switch to cell selection, the cell
selection should be turned back to text selection.

> ...
> If you have a textselection mode, you will not run anymore into 
> cell selection mode as described.
> ...
> So what is your opinion about this?

I would be glad to have by default text selection mode (which doesn't jump to 
cell selection).
(Maybe for cell selection it really should be necessary to press ctrl while 
selecting [with mouse (pressed left key) or with shift+arrow].)

> ...
> If you have a textselection mode, you will not run anymore into 
> cell selection mode as described.
> ...
> So what is your opinion about this?

I would be glad to have by default text selection mode (which doesn't jump to 
cell selection).
(Maybe for cell selection it really should be necessary to press ctrl while 
selecting [with mouse (pressed left key) or with shift+arrow].)

> ...
> If you have a textselection mode, you will not run anymore into 
> cell selection mode as described.
> ...
> So what is your opinion about this?

I would be glad to have by default text selection mode (which doesn't jump to 
cell selection).
(Maybe for cell selection it really should be necessary to press ctrl while 
selecting [with mouse (pressed left key) or with shift+arrow].)

Yes, I'd like that type of functionality: 

1. The user can consciously control the type of selection with a modifier key
(CTRL/SHFT/ALT or any combination).

2. By default it should be text-selection (not cell-selection).

BTW I wonder if we mean the same thing when we say "cell selection": There seem
to be two different possibilities:
>> Select only the text that is highlighted with mouse/keyboard (do NOT let the
highlight spread to the whole text in the cells). But both "text-selection" and
"cell-selection" refer to text only. In other words, text in a cell-structure.

>> "Cell-selection" means select the WHOLE cells, inclusive of their attributes
(=text+border+background+margins,etc)

I was able to reproduce the original bug submitted below on Win 7/AOO 3.3 as well as Win 8/AOO 4.0.1. Below are the steps I followed to replicate the bug.

1. Created a table with 4 rows and 4 columns
2. Input some random data in each of the cells
3. Tried selecting data from R1C1 (calling it A1 here) using Ctrl+Shift+Arrow key. After a certain point (second-last word in cell A1), the highlight jumped to R1C2 (B1)thereby selecting cells A1 and B1. When I continued to highlight using the Ctrl+Shift+Arrow key, the entire table was selected.
4. Later, I tried to deselect a few cells using Ctrl+Shift+(left) Arrow, however,I wasn't able to. 

I also performed a couple of follow-up steps:

1. I checked how this functionality behaved in MS Word. In Word, the highlighting didn't jump into another cell (B1) after second-last word in cell A1. It selected text till the end of cell A1 (cell boundary), and only when there's no additional text in cell A1, then it jumped to B1 and so forth. I was also able to reverse the direction of the highlight at various points using Ctrl+Shift+(back) Arrow keys (which seemed like the right behavior).

2. I also tried in Writer using the combination of Ctrl+Shift+upper arrow key, and it was able to reverse the direction of the highlight and deselect highlight on some of the text. This may or may not yield the exact behavior that raindrops  is looking for, but I saw that this worked (and it worked similarly in MS Word as well). raindrops might want to try this out.

Unexpected jump to next cell when trying to highlight last word in cell. Select to begin of word impossible.

AOO410m17(Build:9763)  -  Rev. 1586584
2014-04-11 09:13 - Linux x86_64
Debian