[This bug was partially described in Bug 43530, which covered more than one distinct issue.] *** SUMMARY *** When creating alphabetical index entries in LibreOffice Writer, if the Insert Index Entry dialog box loses focus (to the document or another application), when the dialog box regains focus: * manually typed or changed Entry data is abandoned and replaced by currently highlighted text in the document; and * manually typed or changed 1st and 2nd Key data is abandoned and replaced by the keys used for the previously inserted index entry. *** EXAMPLE *** [This example is purely for the sake of illustrating the bug, not for illustrating good indexing practices.] SAMPLE DOCUMENT TEXT: From a functional, if not formal, perspective, the "Hexagon" has a national single-payer health insurance system. Switzerland uses a cantonal non-profit all-payer system. STEPS TO REPRODUCE BUG: Index Entry 1: (1) In the document, select "Hexagon". (2) Do Insert > Indexes and Tables > Entry and use the default Alphabetical Index. (3) In the Entry field type "France". (4) In the 1st Key field type "Single-Payer". (5) In the 2nd Key field type "National". (6) Don't click "Insert" yet. Instead, click on the document's scroll bar or switch to an open browser. (If this had been a real document, you might have wanted to scroll up in the document or do a Web search to double-check that "Hexagon" does in fact refer to France.) The word "Hexagon" remains selected in the document, since you haven't clicked inside the document itself, but the Insert Index Entry dialog box has lost focus. (7) Click on the titlebar of the Insert Index Entry dialog box. The dialog box regains focus and the Entry you typed, "France", is gone, replaced by the selected text in the document, "Hexagon". The 1st and 2nd Keys remain unchanged, because this is your first index entry of this LibreOffice Writer session. (8) Retype "France" in the Entry field and click "Insert". Entry 2: (9) In the document, select "Switzerland". (10) Click on the titlebar of the Insert Index Entry dialog box. The Entry field is automatically populated with the word selected in the document, "Switzerland". (11) In the 1st Key field type "All-Payer". (12) In 2nd Key field type "Regional (state, provincial, cantonal, etc.)". (13) Don't click "Insert" yet. Instead, click on the document's scrollbar or switch to an open browser. (If this had been a real document, you might have wanted to scroll up in the document or do a Web search to double-check some aspect of Switzerland's health insurance system.) The word "Switzerland" remains selected in the document, since you haven't clicked inside the document itself, but the Insert Index Entry dialog box has lost focus. (14) Click on the titlebar of the Insert Index Entry dialog box in preparation for clicking on "Insert". The Entry repopulates with the currently selected word in the document, "Switzerland", which is fine because you didn't need to manually change it. However, the 1st Key repopulates with "Single-Payer" and the 2nd Key repopulates with "National", which are the keys for the previous entry ("France"), even though you had entered "All-Payer" and "Regional (state, provincial, cantonal, etc.)" for the current entry. (15) The bug has been fully demonstrated, but to complete the index entry correctly and appreciate how annoying the bug can be, retype "All-Payer" in the 1st Key field and "Regional (state, provincial, cantonal, etc.) in the 2nd Key field and click "Insert". Now imagine having to watch out for unwanted repopulations and having to retype new entries repeatedly. CONCLUSION This behavior -- reverting to the currently selected word in the document and to the previously-entered indexing keys after the Insert Index Entry dialog box has lost focus -- is easy for users to miss and can easily lead to serious indexing errors. I would propose that any manual modifications to the field entries in the Insert Index Entry dialog box be preserved until a new selection is made in the document or the field entries are manually changed by the user. It's fine to PRE-populate the Entry field with currently selected text and the 1st and 2nd Key fields with the keys used for the previously inserted entry, but not to RE-populate them with those once the user has changed them, just because the Insert Index Entry dialog box has lost focus.
TESTING in Ubuntu 14.04 + LO 4.4.0.1 (In reply to Peter CM from comment #0) REPRO steps: > SAMPLE DOCUMENT TEXT: > - Open Writer and copy-in the following text: > From a functional, if not formal, perspective, the "Hexagon" has a national > single-payer health insurance system. Switzerland uses a cantonal non-profit > all-payer system. > Now follow these steps: > Index Entry 1: > > (1) In the document, select "Hexagon". > > (2) Do Insert > Indexes and Tables > Entry and use the default Alphabetical > Index. > > (3) In the Entry field type "France". > > (4) In the 1st Key field type "Single-Payer". > > (5) In the 2nd Key field type "National". > > (6) Don't click "Insert" yet. Instead, click on the document's scroll bar or > switch to an open browser. (If this had been a real document, you might have > wanted to scroll up in the document or do a Web search to double-check that > "Hexagon" does in fact refer to France.) The word "Hexagon" remains selected > in the document, since you haven't clicked inside the document itself, but > the Insert Index Entry dialog box has lost focus. > > (7) Click on the titlebar of the Insert Index Entry dialog box. The dialog > box regains focus and the Entry you typed, "France", is gone, replaced by > the selected text in the document, "Hexagon". CONFIRMED: The 'France' text has been replaced with Hexagon. Definitely looks like a bug to me. Status -> NEW > The 1st and 2nd Keys remain > unchanged, because this is your first index entry of this LibreOffice Writer > session. Actually, the 1st key is now blank. > (8) Retype "France" in the Entry field and click "Insert". > Ok > Entry 2: > > (9) In the document, select "Switzerland". > > (10) Click on the titlebar of the Insert Index Entry dialog box. The Entry > field is automatically populated with the word selected in the document, > "Switzerland". > > (11) In the 1st Key field type "All-Payer". > > (12) In 2nd Key field type "Regional (state, provincial, cantonal, etc.)". > > (13) Don't click "Insert" yet. Instead, click on the document's scrollbar or > switch to an open browser. (If this had been a real document, you might have > wanted to scroll up in the document or do a Web search to double-check some > aspect of Switzerland's health insurance system.) The word "Switzerland" > remains selected in the document, since you haven't clicked inside the > document itself, but the Insert Index Entry dialog box has lost focus. > > (14) Click on the titlebar of the Insert Index Entry dialog box in > preparation for clicking on "Insert". The Entry repopulates with the > currently selected word in the document, "Switzerland", which is fine > because you didn't need to manually change it. CONFIRMED: the Entry stays as 'Switzerland' > However, the 1st Key > repopulates with "Single-Payer" and the 2nd Key repopulates with "National", > which are the keys for the previous entry ("France"), even though you had > entered "All-Payer" and "Regional (state, provincial, cantonal, etc.)" for > the current entry. NOREPRO: The 1st key is now blank, and the 2nd key value remains "Regional (state, provincial, cantonal, etc.)". If I do fill-in the value ("Single-payer") for Key 1 at the end of the first step before I click 'Insert', then I see the described behavior at the end of step 2, with the 1st key changing to Single-payer and the 2nd key changing to National.
Peter: Did this bug exist in previous versions of LibreOffice? If it didn't, then that can help us track down when it was introduced.
(In reply to Robinson Tryon (qubit) from comment #2) > Peter: Did this bug exist in previous versions of LibreOffice? If it > didn't, then that can help us track down when it was introduced. Sorry -- Although I used OpenOffice for around a year back in 2007, I have only been using LibreOffice since around December of 2013. Moreover, I didn't attempt to do any indexing in either suite until very recently, in LibreOffice 4.3.5.2 release. As a result, I can't *personally* say whether the bug is longstanding or newly introduced. HOWEVER, as I mentioned at the start of the current bug report, the problem does seem to be at least partially described in Bug 43530, which was reported in December 2011: "2. I also find that the Index Entry dialogue behaves very peculiarly if you leave it up but go to refer to another file for information or whatever; it reverts to its first entry or qa string of other entries from previous indexing, and it is not clear in any help that I have seen how the up-down arrows and the right and left behave. This has been very frustrating when doing two or three hundred entries!!" There were replies from sasha.libreoffice@gmail (Comments 3 and 4) that seemed to confirm the problem, characterizing it an inappropriate autocompletion issue. However, the bug was apparently never assigned. I'm pretty sure the author of Bug 43530 didn't identify which versions of OpenOffice and LibreOffice he had experienced the behavior on, but we have a pretty good idea that it has been around at least since whatever versions were the most recent as of December 2011. (And since I get the impression that the author was an ordinary non-coder user, like me, I'd guess that he was using stable releases, also like me.)
(In reply to Robinson Tryon (qubit) from comment #2) > Peter: Did this bug exist in previous versions of LibreOffice? If it > didn't, then that can help us track down when it was introduced. I'm curious why you were unable to reproduce the same field-repopulation behavior I experienced. I can think of two possibilities: * In developing the example, I may have done complete, correct entries for France and Switzerland, deleted the entries, and then proceded with the test. It's possible that LibreOffice remembered the keys for those entries even though they were no longer in use anywhere in the document. * In retrospect, I'm pretty sure I developed the habit out tabbing out of the 2nd Key field after completing it in a vain attempt to protect it from repopulation/autocompletion. If so, I should have included two additional steps: (5.1) Tap the tab key to tab out of the 2nd Key field. (12.1) Tap the tab key to tab out of the 2nd Key field. the second part of step (14). It's quite possible that I did an additional. I guess it's useful to know the exact behavior in order to diagnose and fix the problem, but whether we get your results or mine, in both cases manually typed index entries and keys are abandoned when the Insert Index Entry dialog box loses and regains focus before the index entry has been inserted. Since indexing can require a lot of double-checking, this is something that can potentially happen a great deal, resulting in a lot of duplicated effort. A workaround would be for users to do *all* of their double-checking before beginning the entry -- but (1) users often don't realize they need to double-check something until *after* they have typed it, and (2) some entries and keys (e.g., with unfamiliar foreign spellings) are more safely copied-and-pasted than manually typed. I really appreciate that you took the time to look into this bug and have confirmed its essence. Best wishes for the coming year.
I just confirmed that this bug remains unfixed in LibreOffice 5.0.0.5. It is easy to reproduce in any document. It is not just very annoying; it seriously hampers the productivity of anyone who does serious indexing work and who needs to double-check or copy-and-paste information into the entry, 1st key, and 2nd key fields. The workaround requires an incomplete or incorrect entry to be made and subsequently edited in a separate operation. This easily doubles the amount of time required for indexing and increases the likelihood of errors, especially when the document has multiple index entries immediately adjacent to each other. It needs to be fixed, and although I a not a coder, it doesn't strike me as that difficult a challenge. Maybe the best solution is to combine Insert Index Entry and Edit Index Entry functions into a common dialog. But if you want to maintain separate insert and edit dialogs, don't dump manually added content until the user okays it. Don't reset or repopulate manually filled Insert Index Entry fields until the user has clicked the OK button or exited the index entry box. Thanks!
Similar to qubit, after regaining focus to the insert index entry dialog in step 7, the 1st key field is blank, but different than qubit, step 14 did have 'Single-Payer' and 'National'. It would be good to get ux-advise on how this non-modal dialog should react after it regains focus. I tested the hyperlink dialog and it doesnt react like this. Once the hyperlink dialog is open, only when you reselect text in the document does the text in the 'Text' field autoupdate without the dialog regaining refocus.
(In reply to Yousuf (Jay) Philips from comment #6) > Similar to qubit, after regaining focus to the insert index entry dialog in > step 7, the 1st key field is blank, but different than qubit, step 14 did > have 'Single-Payer' and 'National'. > > It would be good to get ux-advise on how this non-modal dialog should react > after it regains focus. I tested the hyperlink dialog and it doesnt react > like this. Once the hyperlink dialog is open, only when you reselect text in > the document does the text in the 'Text' field autoupdate without the dialog > regaining refocus. I really appreciate your follow-up on this. In my view, no manual changes to an Insert Index Entry dialog should be discarded until the user clicks Insert or Cancel or Close. (Cancel would have to be a new button.) There are certainly more functionalities that could be added to the dialog -- for example, settings that allow the user to choose default field population behavior (blank, static/previous, auto), and controls for quickly manipulating individual field contents in individual entries (blank, previous, auto, undo, redo) -- but these ideas are best submitted as a feature or enhancement request. I haven't thought it through, nor have I studied other indexing systems, but there may be a good case for combining the Insert Index Entry and Edit Index Entry dialogs in a single dialog. The important thing for now is to stop discarding manually entered indexing data just because the dialog box has lost and regained focus before the entry is inserted. Leaving the dialog box temporarily to double-check or copy something happens *all the time* when you're indexing.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b7060e96dfef8e672ae954eb435a9513400c4ea9 Resolves: tdf#87686 don't refresh index entry from selection on regain focus It will be available in 5.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I've gone with simply not automatically updating the index dialog entries from the selection on regaining focus, but added a little refresh button that does the old "update from selection" thing when clicked on. So user edited contents remain untouched unless asked to throw away and refetch from selection
(In reply to Caolán McNamara from comment #9) > I've gone with simply not automatically updating the index dialog entries > from the selection on regaining focus, but added a little refresh button > that does the old "update from selection" thing when clicked on. So user > edited contents remain untouched unless asked to throw away and refetch from > selection nice - thanks!
(In reply to Caolán McNamara from comment #9) > I've gone with simply not automatically updating the index dialog entries > from the selection on regaining focus, but added a little refresh button > that does the old "update from selection" thing when clicked on. So user > edited contents remain untouched unless asked to throw away and refetch from > selection As it happens, I'm still doing some indexing work off and on and am looking forward to testing the fix. I've pinned http://dev-builds.libreoffice.org/daily/master/ in my browser, but although I do have experience with parallel installs (via Separate Install GUI for Windows), this will be my first time working with daily builds and I'm uncertain which subdirectory to go into. I'm running 64-bit Windows 7 and normally prefer to work with 64-bit versions of LibreOffice, but I'm open to either x86 or x64 (or both) for testing purposes. Which subdirectory or subdirectories should I be looking for? In the meantime, thanks very much for your work on this extremely annoying bug!
I did a parallel install of master~2016-08-13_09.30.32_LibreOfficeDev_5.3.0.0.alpha0_Win_x64_en-US_de_ar_ja_ru_qtz in Windows 7. (I got fatal errors trying to load it with a copy of the profile I use for my "fresh" LibreOffice 4 and 5 installs, as well as with a new blank profile, so I had to work with UserInstallation=$ORIGIN/.. in the bootstrap.ini file. I rely on my macros and toolbar customizations quite heavily, so I won't be doing very much testing with this build, given that I can't use a copy of my profile.) The GREAT NEWS: The fix appears to work as advertised and is a DRAMATIC improvement over the previous behavior. Thank you, Caolán. (I *believe* this is the second time someone from Red Hat has fixed a bug I reported, and I won't forget it or keep it to myself.) The inevitable CAVEAT: If you leave the Insert Index Entry dialog box up, open the Edit Index Entry dialog box, go back to edit a previous index entry -- and don't necessarily even commit the edit; just opening an entry in the edit dialog seems to suffice -- then close the Edit Index Entry dialog box, highlight a new selection in the document, and click on the "Update entry from selection" button, the contents of the Insert Index Entry dialog box's 1st and 2nd Key fields change to something different from the last entry you inserted or edited. (I haven't identified a clear pattern for how they populate yet.) I suppose this is a separate bug, one that I had already noticed before the instant bug was fixed. OBITER DICTA: As I believe I mentioned earlier in this thread, I'm not an experienced indexer and I haven't used other indexing systems. Accordingly, I can't say whether there are any compelling "workflow" arguments for having one dialog for inserting new index entries and a separate dialog for navigating between and editing or deleting them. However, although I'm also not a coder, I'd speculate that if inserting, navigating, editing, and deleting were all handled by a single indexing dialog, the coding might be more straightforward and less susceptible to untoward interactions like the one mentioned in my caveat. But I honestly don't know if it's a good idea on balance. An experienced professional indexer would have to weigh in. CONCLUSION: If you think it's advisable, I'll file a separate bug report for the edit/insert interaction, but In the meantime, I'm thrilled and grateful for your fix and look forward to a fresh release that incorporates it. Thanks again, and all the best.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=5b9480b5d29a7f5fc4ba509f180a71b162451b34 Related: tdf#87686 on refresh from selection, only consider the edit updated It will be available in 5.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.