Description: Edit --> Fields... (in Writer) fails to highlight or otherwise indicate the current field while navigating forward and backward, making locating the field in question cumbersome and slow. This is particularly problematic in large, text-heavy documents containing many fields. Neither IBM Lotus Symphony nor Apache OpenOffice has such an issue, but it is a result of poor programming changes in LibreOffice's Edit Fields dialogue. Please fix this so that LibreOffice is more usable for fields-laden documents. Steps to Reproduce: 1.Locate a field, and then go to Edit --> Fields... 2.Use the left and right "arrow" (triangle) buttons to move to the prior or next field in the document. 3.Notice that the current field in the document is NOT highlighted, the cursor is NOT blinking or visible near it, and you have to actually READ through all the text on the page to try to locate the field in question. That's a total pain and a waste of time and productivity. Actual Results: The current field is NOT evident when moving to it. Expected Results: As in Apache OpenOffice 4.x and IBM Lotus Symphony 3, the current field to which one has navigated using the Edit Fields dialogue's previous or next button should be made obvious by being highlighted or evidently selected, but that is NOT occurring even in the latest version of LibreOffice. Reproducible: Always User Profile Reset: No Additional Info: OpenGL is NOT enabled.
Not sure, if I understand your problem. Have you enabled field shading (View -> Field shading or Strg+F8) => NEEDINFO
Yes, Field Shading IS enabled. The problem is that when using the forward and backward carats (buttons) in the Edit Fields dialog, the currently selected field is NOT being indicated in the document itself on a given page: there is NO additional highlighting, no blinking cursor in the document, etc. This is NOT an issue with the old Edit Fields dialog found in IBM Lotus Symphony (1.2, 1.3 and 3) NOR is it an issue in Apache OpenOffice 4.x, as those other products DO actually indicate the selected field when navigating in the Edit Fields dialog. If this does not clarify the issue for you, then I recommend you install Apache OpenOffice 4.x, and compare what happens when you use the forward and backward buttons in the Edit Fields dialog of OpenOffice as it moves from one selected field to another in the document, versus what occurs in LibreOffice 7.x; in OpenOffice, the current field is very obvious in the document itself, but LibreOffice gives NO indication at all within the document of which field is selected (e.g., if there are multiple fields on a page) in the document.
I confirm the described behaviour with Version: 7.0.2.2 (x64) Build ID: 8349ace3c3162073abd90d81fd06dcfb6b36b994 CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win Locale: he-IL (de_DE); UI: en-GB Calc: threaded I don't know, if this is a bug or the correct current behaviour (which can be improved). So I would treat it as enhancement request at the moment and ask design-team for further input and decision. Presonally I would support the idea, because in a document with a lot of fields it would be helpful to make the selected field more visible.
Confirmed. Version: 7.0.1.2 (x64) Build ID: 7cbcfc562f6eb6708b5ff7d7397325de9e764452 CPU threads: 8; OS: Windows 10.0 Build 18363; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL That lack of a visual queue on canvas as to which field object has dialog focus is annoying. Not critical, but annoying when field sequence for source template was not well ordered and labeled. There should probably be some linkage between field object with focus on canvas and one of the controlling Field dialogs--uno:AddField, uno:insertFieldCtrl, uno:FieldDialog, uno:UpdateField, uno:InsertFields, uno:UpdateInputFields -- and as well the Go to Next/Prev input field controls.
Possible solution is to place the caret at the field or use the highlighting from find.
(In reply to Heiko Tietze from comment #5) > Possible solution is to place the caret at the field or use the highlighting > from find. The Text caret should visibly reposition in response to the dialog(s) and controls, for sure. But any thought on why Find bar (or now Navigator) has never included a Field object? Seems like low hanging fruit...
(In reply to Heiko Tietze from comment #5) > Possible solution is to place the caret at the field or use the highlighting > from find. No, that is NOT a solution at all. You need to actually read the bug / issue report. Your suggestion would accomplish nothing in this case.
(In reply to V Stuart Foote from comment #6) > (In reply to Heiko Tietze from comment #5) > > Possible solution is to place the caret at the field or use the highlighting > > from find. > > The Text caret should visibly reposition in response to the dialog(s) and > controls, for sure. > > But any thought on why Find bar (or now Navigator) has never included a > Field object? Seems like low hanging fruit... I suspect that the Navigator has not included the Field object simply because there is a need to update / fix a broken field when a referenced Bookmark is inadvertently deleted, for example. However, I definitely agree with you that Fields should be included as navigable items in the Navigator, and that they should ADDITIONALLY be in that tree, which would be very helpful as well. Neither IBM Lotus Symphony versions nor Apache OpenOffice versions have ever included Fields in their "navigator" features either, though that really should have been included from the start IMO. And yes, that probably is low-hanging fruit, but being unfamiliar with the codebase, I'm not sure.
(In reply to TH from comment #7) > (In reply to Heiko Tietze from comment #5) > > Possible solution is to place the caret at the field or use the highlighting > > from find. > > No, that is NOT a solution at all. You need to actually read the bug / > issue report. Your suggestion would accomplish nothing in this case. (In reply to TH from comment #0) > Edit --> Fields... (in Writer) fails to highlight... > 3.Notice that the current field in the document is NOT highlighted, the > cursor is NOT blinking or visible near it... Caret = blinking cursor, highlighted as in find = blueish background; fact is that we scroll to the right page but on this page the actual field has no indicator.
Hi all, Looking at the code change history this seems to be a regression caused by commit f51005bc969c9296fa3e64d82c13f84fdfb90fe4 Here is an attempt, not thoroughly tested, to restore functionality: https://gerrit.libreoffice.org/c/core/+/104100
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/e385efc6bf5d084759be4fd02f272a75c053fbc5 tdf#137210 fix field selection regression It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I will check the resolution soon, to see if it works properly for me. What about adding Fields to the Navigator tree as well? Has anything been done on that? Also, I earlier submitted new bugs / issues with Ids 137272 and 137296, but have had no response and seen no movement on either of those, and both are critical if LibreOffice is to seriously contend in the future with the likes of MS Word or Corel WordPerfect, for example. Can any of you please take a look, and see if it's possible to get some movement on those as well? Thanks!
(In reply to TH from comment #12) > I will check the resolution soon, to see if it works properly for me. TH, I don't understand, why you've changed status to UNCONFIRMED. Please test, if the bug has been solved. If it is solved please change status to VERIFIED FIXED, if it is not solved you can change status to REOPEN. > What > about adding Fields to the Navigator tree as well? Has anything been done > on that? Please don't mix two different issues in one bug.
"> What > about adding Fields to the Navigator tree as well? Has anything been done > on that? Please don't mix two different issues in one bug." REGARDING the above, IS there an existing issue for the inability to navigate among Fields using the Navigator tree? Or is that something I should create as new? Thanks!
(In reply to TH from comment #14) > REGARDING the above, IS there an existing issue for the inability to > navigate among Fields using the Navigator tree? Or is that something I > should create as new? I couldn't find such a bug, so please file a new report (I think it's an enhancement request).
(In reply to Dieter from comment #16) > (In reply to TH from comment #14) > > REGARDING the above, IS there an existing issue for the inability to > > navigate among Fields using the Navigator tree? Or is that something I > > should create as new? > > I couldn't find such a bug, so please file a new report (I think it's an > enhancement request). done as bug 137741