Apache OpenOffice (AOO) Bugzilla – Issue 98999
If selection within input line of Calc is not reflected within the corresponding cell, then an entered change is lost
Last modified: 2014-01-02 15:33:51 UTC
1. enter a few words in each of four cells A1 B1 A2 B2 2. escape 3. command-click B2, do not release the command key 4. command-click A2, do not release the command key 5. command-click B1, do not release the command key 6. command-click A1 — without moving the cursor away from cell A1 7. release the command key 8. observe selection of the four cells — aim for the input line — without double-clicking anywhere within the input line 9. click the beginning of a word in the midst of the input line 10. observe de-selection of the corresponding cell 11. observe the remaining highlight of the other three cells 12. drag to the end of the word (select) 13. observe the matching selection of one word in cell A1 = Bug = Selection of text within the input line is sometimes/often _not_ matched by a selection in the corresponding cell. I see this often, more often than not, but I can't figure out exactly how to reproduce it. Whenever this occurs: * any edition of the text in the input line will be lost when the user keys Enter or Return. Now, whilst reporting: I see the bug even when there is highlight/selection of no more than one cell; but I'll leave this report as it is, because I noticed the bug first after non-contiguous (command-click) selection of cells. I'll attach screen shots demonstrating the mismatch and the loss of edition.
Created attachment 60004 [details] the word minim is selected in the input line but _not selected_ in the corresponding cell
Created attachment 60005 [details] the overtype in the input line is _not reflected_ in the corresponding cell
Created attachment 60006 [details] return key moves to the next cell and _loses the user's edit_
Created attachment 60007 [details] an example of a properly reflected selection
Created attachment 60008 [details] the word amet is selected in the input line but _not selected_ in the corresponding cell
Created attachment 60009 [details] the overtype in the input line is _not reflected_ in the corresponding cell
When the selection in the input line is not reflected in the corresponding cell, * Enter key moves to the next cell and _loses the user's edit_
Created attachment 60010 [details] demonstrating that mismatch also occurs without a highlight of the corresponding cell
Created attachment 60011 [details] demonstrating again that a press of the Enter key loses the user's edition
Created attachment 60015 [details] Name Box specifies A1; A1 not highlighted; three neighbours highlighted; the word selected in the input line is not selected in A1
Considering this issue 98999 > If selection within input line of Calc is > not reflected within the corresponding cell, > then an entered change is lost alongside issue 99001 > highlight is sometimes lost from > selected column headings and selected row headings I wonder whether OOo is reacting strangely before, during, or after normal use of the command (Apple) key: • in combination with tab key (switching between applications) • in combination with single mouse clicks (non-contiguous selections). Very difficult to reproduce exactly but in my tests this afternoon/evening I do find that more often than not, a selection in the input line is _not_ matched in the corresponding cell (and so, edition is lost).
Bug issue 99002: > double-click wrapped text within a cell that has > white space above the text: insertion point is > misplaced beyond the aim of the user's double click Whilst an excess of white space (above wrapped text) may not be visible in examples in this issue 98999 or issue issue 99001, I wonder whether a misinterpretation of the user's aim (the user's single click) is contributory to this issue.