Description: Insert cross-reference: The dialog box has a section 'Selection'. In the 'Filter Selection' field, the user can write the number of the object he wants to cross-reference. - The filtered list below offers not only the numbered objects themselves, but also references to them. The latter are not wanted; the user wants to refer to a numbered object, not to a reference. - Once the list of numbered objects has shrunk down to a single object, this is what the user wants to cross-reference. The cursor should then automatically move down to select this object, so that it will suffice for the user to hit Return. (Both of these features used to be okay in Writer up to and including LO 5.) Steps to Reproduce: 1. Hit ALT-i. 2. Choose 'Cross-reference'. 3. Click in 'Filter Selection'. 4. Type initial characters of reference sought. Actual Results: 1) In the area below the Selection field, the numbered object is listed, but also references to it. 2) The graphic cursor remains in the Selection field even if the single fitting object is identified. Expected Results: 1) Only the numbered object itself should be listed (as it used to be case in earlier versions of LO). 2) If only one object is listed, the cursor should highlight it. Reproducible: Always User Profile Reset: No Additional Info: These are really enhancements rather than bugs. However, the enhancements suggested are not new; they are properties that were present in earlier versions. Their destruction amounts to a bug.
Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided. (Please note that the attachment will be public, remove any sensitive information before attaching it)
Created attachment 171231 [details] odt file to demonstrate the bug The sample document 'test.odt' contains many occurrences of "Error: Reference source not found" because it is an excerpt of a much larger file. This is immaterial to the problem at hand. First try: At any position in the document, I want to insert a reference to section 2.1.3. Hit: Insert > Cross-reference Type: Numbered Paragraphs Insert reference to: Number (no context) Selection: 2.1.3 Result: The list below the selection field contains 11 (pseudo-)hits. Only the first one is correct. The next two lines are paragraphs that contain a reference to section 2.1.3. Should not be listed. The following lines show headings whose number includes the sequence 2.1.3. Should not be listed. Second try: At any position in the document, I want to insert a reference to section 1.1.2. Hit: Insert > Cross-reference Type: Numbered Paragraphs Insert reference to: Number (no context) Selection: 1.1.2 Result: A single target is shown. Correct. However, the cursor should be in the list field, marking the target found, so that it suffices for me to hit 'Insert'.
[Automated Action] NeedInfo-To-Unconfirmed
(In reply to Christian Lehmann from comment #2) > Type: Numbered Paragraphs Please choose "Headings" instead Numbered paragraphs is every paragraph with a (numbered) list > However, the cursor should be in the list field, marking the target found, > so that it suffices for me to hit 'Insert'. LO displays result from the moment you start typing. So for me it's expected, that Searching filed is still active. Does this solve your problem? => NEEDINFO
On the one hand, I find it pleasant to receive advice how I can circumvent problems that I encounter. On the other hand, they sometimes tend to downplay the existence of a real bug. 1) I could, of course, choose 'Headings' as Type whenever I want to refer to a section. However, equally often I want to refer to a numbered paragraph which is not a heading. I would then have to select the Type at every given instance, which amounts to as much work as the target selection which I complained about in the first place. Even in the Headings list, headings are shown which I am not looking for. E.g., always using the sample file I provided and having selected Type 'Headings', type "2.1.1" in the Selection field. Beside the heading looked for, you will see another one (2.2.2.1.1) which you did not look for (if you were searching it, you would type "2.2.2." etc.) Needless to say, the problem I reported is the same if you reference some object which is not a heading. E.g., start typing "e28" in the Selection, and you will see a paragraph in the list that does not belong there. 2) As to your comment "LO displays result from the moment you start typing. So for me it's expected, that Searching filed is still active." we may have a misunderstanding. Select Type "Headings" and, in the Selection field, type "2.1.2.1". This identifies a single target. In the list field, this should automatically be highlighted (as it used to be the case in earlier LO versions). Instead, the cursor remains in the Selection field.
If I understand correctly, Christian Lehmann wants the "Selection" input field, where user types something to filter the results, to only take numbers into account, not the text of the numbered paragraph? It would be absolutely wrong for most of the users, who may want to type the text and find the corresponding item, and only makes sense for users who somehow know all their numbers in a heavily numbered document (well, I hardly imagine many people who know by heart all the numbers in a document with hundreds of numbered paragraphs, while I easily know people who may reasonably remember some part of text in the item they need).
(In reply to Christian Lehmann from comment #5) > Select Type "Headings" and, in the Selection > field, type "2.1.2.1". This identifies a single target. In the list field, > this should automatically be highlighted (as it used to be the case in > earlier LO versions). Instead, the cursor remains in the Selection field. I confirm that in Version: 6.2.0.3 (x64) Build ID: 98c6a8a1c6c7b144ce3cc729e34964b47ce25d62 CPU threads: 12; OS: Windows 10.0; UI render: GL; VCL: win; Locale: ru-RU (ru_RU); UI-Language: en-US Calc: CL typing '2' in the Selection makes the top element on the filtered list to be selected, while starting from Version: 6.3.0.4 (x64) Build ID: 057fc023c990d676a43019934386b85b21a9ee99 CPU threads: 12; OS: Windows 10.0; UI render: GL; VCL: win; Locale: ru-RU (ru_RU); UI-Language: en-US Calc: CL typing '2' makes the resulting list to *not* have any selection. I don't know if this was intentional, or some accidental breakage from, say, welding work. Marking bibisectrequest *for this aspect only*.
(In reply to Mike Kaganski from comment #7) > If I understand correctly, Christian Lehmann wants the "Selection" input > field, where user types something to filter the results, to only take > numbers into account, not the text of the numbered paragraph? It would be > absolutely wrong for most of the users, who may want to type the text and > find the corresponding item, and only makes sense for users who somehow know > all their numbers in a heavily numbered document (well, I hardly imagine > many people who know by heart all the numbers in a document with hundreds of > numbered paragraphs, while I easily know people who may reasonably remember > some part of text in the item they need). This is a misunderstanding. 1) If I want to refer to the object numbered 'X', then I type 'X' in the selection field and I only want to see that exact paragraph which is numbered 'X', and not dozens of paragraphs which happen to contain the expression 'X'. 2) The question of how I know that it is X that I want to refer to is a different one. If it is a heading, then my method is to look at the Navigator. Searching for a word or string that is part of the heading would be inefficient since that string may occur dozens of times in numbered paragraphs of all sorts. However, if you want to offer the user alternative ways of finding the paragraph he wants to refer to, then we are not talking about Types of reference targets (that is what the dialog field is called), but about search strategies. You may then wish to offer: a) Search by number [where 'number' means 'paragraph/heading/footnote etc. number] b) Search by content.
(In reply to Christian Lehmann from comment #9) > This is a misunderstanding. > 1) If I want to refer to the object numbered 'X', then I type 'X' in the > selection field and I only want to see that exact paragraph which is > numbered 'X', and not dozens of paragraphs which happen to contain the > expression 'X'. Heh, no. This was not a misunderstanding on *my* part, but you substitute a discussion of "what is best for most" with your personal preference. Quite valid as an enhancement request, no problem in that. > However, if you want to offer the user alternative ways of finding the > paragraph he wants to refer to, then we are not talking about Types of > reference targets (that is what the dialog field is called), but about > search strategies. You may then wish to offer: > a) Search by number [where 'number' means 'paragraph/heading/footnote etc. > number] > b) Search by content. So your proposal seems to be "allow me to search by number only, in addition to the already existing method of searching by matching in any place of paragraph text". I agree that would be a valid enhancement (though not trivial, since Writer's link provider only gives strings, not structure internally - but that's an implementation detail that user does not have to think about), unless a simple "match from the start of the paragraph text" would suffice.
The reference to a numbered target has the same number as its target, otherwise the reader would hardly be able to follow it up. Since the target is identified by the reference, it is a natural user strategy to use its number in the selection field in order to pin it down. This is not a "personal preference" of mine, but has been standard in earlier versions of LO. It is true that in my former post, the word 'I' was used to refer to the user. I will not repeat this mistake. It is not a fruitful communication strategy to personalize an exchange whose object is the functionality of LO. As long as there is sufficient evidence that a certain behavior of LO would be useful for a set of users, the question of whether the reporter or the developer have a personal preference for it is of little importance. Now as to the technical aspect: It is true that in the Numbering Styles, Writer allows for Numbering alignment not only at the left, but also at the right side and even centered. So as long as the link provider does not identify the "number" of a numbered element (where, in LO jargon, a "number" is anything used to label a paragraph), it is true that the enhancement proposed would initially only work for numbers in initial position, as you say. (Users numbering mathematical or logical formulas at the page margin would be disadvantaged by that.)
(In reply to Christian Lehmann from comment #11) > This is not a "personal preference" of mine, but has been standard in > earlier versions of LO. No, I have checked in all 10 major versions starting from v. 5.2 (where the selection box was introduced [1]). and it was always the same: it searched the entered text anywhere in the text of paragraph. E.g., entering "3.2" would bring 13 results, including "2. final infinitival: ch. 2.1.3.2." and "2.2.2.1.3.2. Frustrated action construction". Furthermore, as I mentioned above, it is incorrect to imply that the preference to use numbers in the search is universal; in writing, the numbering is automatic, and user often does not even know which number one of the point might have at any given time, because of added or removed or restructured points above. > As long as there is sufficient evidence that a certain behavior of LO would > be useful for a set of users, the question of whether the reporter or the > developer have a personal preference for it is of little importance. Your proposal was re-worded at the end of comment 10 to follow that idea :-) > Now as to the technical aspect: It is true that in the Numbering Styles, > Writer allows for Numbering alignment not only at the left, but also at the > right side and even centered. So as long as the link provider does not > identify the "number" of a numbered element (where, in LO jargon, a "number" > is anything used to label a paragraph), it is true that the enhancement > proposed would initially only work for numbers in initial position, as you > say. (Users numbering mathematical or logical formulas at the page margin > would be disadvantaged by that.) Yes. [1] https://wiki.documentfoundation.org/ReleaseNotes/5.2#Selection_Filter_in_Cross_Reference_Tab
(In reply to Mike Kaganski from comment #12) > (In reply to Christian Lehmann from comment #11) > > This is not a "personal preference" of mine, but has been standard in > > earlier versions of LO. > > No, I have checked in all 10 major versions starting from v. 5.2 (where the > selection box was introduced [1]). and it was always the same: Okay, then that was out of unreliable memory. Then please just take into account the user who uses the Navigator to identify the targets for references to sections.
(In reply to Christian Lehmann from comment #13) > (In reply to Mike Kaganski from comment #12) > > (In reply to Christian Lehmann from comment #11) > > > This is not a "personal preference" of mine, but has been standard in > > > earlier versions of LO. > > > > No, I have checked in all 10 major versions starting from v. 5.2 (where the > > selection box was introduced [1]). and it was always the same: > > Okay, then that was out of unreliable memory. Then please just take into > account the user who uses the Navigator to identify the targets for > references to sections. Then please decide what to do with this bug, taking into account that this bug must continue with only one of the two different issues: 1. A regression (or was it deliberate decision?) that selection in the list disappears as soon as initially selected item gets filtered out (this is why I marked this bibisectrequest in comment 8); 2. An enhancement request to allow limiting filtering to numbers only. Please keep this bug only for one of the two (and update title, pointing to a comment that provides an updated summary), and please file the other separately.
So summarizing the regression: In the dialog for insertion of a cross-reference, the user has typed in the Selection field enough text to reduce the list of possible targets to one. In this moment, the target for the reference should be highlighted so that it suffices for the user to press the OK button.
The enhancement proposed is now deferred to Bug 141777.
(In reply to Christian Lehmann from comment #15) > So summarizing the regression: > In the dialog for insertion of a cross-reference, the user has typed in the > Selection field enough text to reduce the list of possible targets to one. > In this moment, the target for the reference should be highlighted so that > it suffices for the user to press the OK button. Mike confirmed this bug in comment 8 => NEW
Closely related to this bug: Produce the following situation: In the Selection field of the Cross-reference dialog, you have entered enough text to produce a list of possible targets in the field below it. Now press TAB to jump to the first entry of this field. This should now be highlighted. It is not, so you are misled to the impression that TAB did nothing.
Dear Christian Lehmann, 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 https://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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Comment 18 is a real bug. It persists in the most recent versions of LO. Comment 15 is an enhancement. It has not been taken care of, either. They are treated here in one bug report because they obviously concern the same user action and could be remedied on one go.
(In reply to Mike Kaganski from comment #8) > (In reply to Christian Lehmann from comment #5) > > Select Type "Headings" and, in the Selection > > field, type "2.1.2.1". This identifies a single target. In the list field, > > this should automatically be highlighted (as it used to be the case in > > earlier LO versions). Instead, the cursor remains in the Selection field. > > I confirm that in Version: 6.2.0.3 (x64) > Build ID: 98c6a8a1c6c7b144ce3cc729e34964b47ce25d62 > CPU threads: 12; OS: Windows 10.0; UI render: GL; VCL: win; > Locale: ru-RU (ru_RU); UI-Language: en-US > Calc: CL > > typing '2' in the Selection makes the top element on the filtered list to be > selected, > > while starting from Version: 6.3.0.4 (x64) > Build ID: 057fc023c990d676a43019934386b85b21a9ee99 > CPU threads: 12; OS: Windows 10.0; UI render: GL; VCL: win; > Locale: ru-RU (ru_RU); UI-Language: en-US > Calc: CL > > typing '2' makes the resulting list to *not* have any selection. > > I don't know if this was intentional, or some accidental breakage from, say, > welding work. Marking bibisectrequest *for this aspect only*. Bibisected with linux-64-6.3 to c403c86c6da4db0a6f2864ad4e13def9a3898cd4 weld SwFieldRefPage Steps: 1. Open attachment 171231 [details] 2. Insert - Cross-reference 3. Ensure Type is Headings 4. Type 2 into the Selection field
I think those list widgets just used to implicitly auto select the first entry (if there was any). That's the simplest state to restore to, so https://gerrit.libreoffice.org/c/core/+/171514 for that
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/874e93d02ae4875db226a855ac06c33d3b093cd5 Resolves: tdf#141398 auto-select first entry of filtered results It will be available in 25.2.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.
backport to 24-8 and 24-2 in gerrit
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/1f909d67b4555b0ea7299e69af028dab54619007 Resolves: tdf#141398 auto-select first entry of filtered results It will be available in 24.8.1. 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.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/2081b0d4ff4fe3f317db65ed9e7b93aeebb09936 Resolves: tdf#141398 auto-select first entry of filtered results It will be available in 24.2.6. 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.