Created attachment 130983 [details] Documents does not allow to access empty cells. I have a table, that was initially created with LibreOffice, and then opened with WORD due to 97599 to have the styles re-added. When I open the file in LibreOffice, it is impossible select the cells without content. The cells behind B and H can be clicked, in order to change the style or insert something; an empty cell like the one behind E cannot be reached, for example to insert a number or to change the format. It is of course possible in WORD. I still hope to be able one day to do all my office work in LibreOffice, though this here is another 'impossible' blocker for me, since I have to identify correct solutions, and modify a style. I have added a simple document as example. What needs to be done can be done in WORD, not in LibreOffice.
Confirmed in Version: 5.4.0.0.alpha0+ Build ID: fc53cce64400430cdc21f79c959d75fb9a26d13d CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk2; Locale: ca-ES (ca_ES.UTF-8); Calc: group and LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4
I've been also affected by this bug. It is very stressful to have to deal with such a basic thing. Furthermore, the only way to fix it I found, was to use Microsoft Word, fill in the empty cells, save it, and then, and only then I was able to edit all fields in LibreOffice. Very far from desirable. I love using LibreOffice, but until this bug is fixed, I cannot recommend it for production use to my colleagues.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still true in LO 7.1+
Created attachment 173727 [details] The example file in Word and Writer The content (default end-of-cell marker) of those cells has the Hidden character attribute enabled. Now in Word by default the Hidden characters are shown, but even if hidden this end-of-cell marker is exempt from that, making it possible to click into the cell and edit it. Writer does not have a special end-of-cell marker so empty cells are marked by paragraph markers. Hidden characters are also hidden by default, they can be enabled under Options - Writer - Formatting Aids - Hidden characters. Paragraph markers are affected by having the Hidden character property - both in Word and Writer - so they are hidden when the file is opened. My subjective observation is that Word really tries hard to discourage users from using these hidden characters: By default, they are visible, then if you manually hide them in its Settings, it's enough to type into a hidden empty paragraph to enable the "Show all formatting marks" option in the Settings, which overrides the "Hidden text" option.
An actionable change could be to enable by default the Hidden characters option in Options - Writer - Formatting Aids. Apart from solving this issue that would match our UX to Words, and serve to discourage users from applying the Hidden character attribute. It's not a very efficient way to hide information from others anyways. But of course this would unavoidably break some peoples workflow, so needsUXEval.
(In reply to NISZ LibreOffice Team from comment #6) > An actionable change could be to enable by default the Hidden characters > option in Options - Writer - Formatting Aids. Bad solution, but showing independently from the option at empty cells sounds good to me.
May I respectfully disagree? A writer application must be simple, logical and straightforward. Meaning, any cell in a table must be accessible by default; not through any workaround. It would be a huge frustration to the average user (maybe not to me) to search a knowledge base to find out how to fill an empty cell in a table.
Looking again into this issue I believe it's not a bug. The non-clickable cells have set characters to be hidden - even when you enter text it will disappear when editing is done. I guess the original authors intended this as a safety feature. Point is that hidden text cannot be selected.
I an only shake my head in disbelieve. Yet another 'bug is no bug but a feature'. Firstly, the behaviour is different from MS PP. It used to be one of the aims to be comparable. Second, the previous argument seems to imply, that I ought not be able to change a hidden text attribute at all. Not in a table. That is, I must not be able to go and modify a text attribute at all, and not be able to modify a cell content. It won't help much, I'm afraid, to reopen it. Despite of me being unable to see any common sense in said action.
To change hidden text you have to show it. Admittedly, there is no indicator like you get in normal text when field shading is on.
If you know what is wrong with the document, it is fairly easy to select a range of cells and turn the Format - Character - hidden property off. If you don't know what is wrong the document, I imagine it would be hard to figure out no matter whether you can (easily) get the cursor into the cell or not. Even in MS Word 2003 I had to select the entire cell in order to turn off the hidden format, so the method of "fixing" this document is already the same for both Word and LO - just that LO can't just select only the hidden cell (at least not "out of the box"). I am completely baffled why "nothing content" has been marked as hidden in this document. Lowering the importance since it is an odd-ball example dealing with character hiding - which by definition is not a "simple document". Also lowering it because anyone intentionally using hidden text in LO should know about Tools - Options - Writer - Formatting Aids - Display Formatting: Hidden characters. Things work "as expected" when that is turned on.
Created attachment 180950 [details] ShowHiddenChars.oxt: configuration extension to default showing hidden content with "Toggle Formatting Marks"
(In reply to Heiko Tietze from comment #9) > Looking again into this issue I believe it's not a bug. I agree this is not a bug. The decision was made long ago not to show hidden content, and the option for a user to do it anyway has long been in place and should be easy to find with a google search. (In reply to Heiko Tietze from comment #11) > Admittedly, there is no indicator > like you get in normal text when field shading is on. Irrelevant - that is only for fields. There is no indication if Format - Character - Hidden is enabled on normal paragraph text - which is what we are dealing with here in the cells.