Bug 126527 - Find & Replace dialog: Search for formatting dialog adds unchosen formats (see comment 4)
Summary: Find & Replace dialog: Search for formatting dialog adds unchosen formats (se...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.1.6.3 release
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:6.4.0
Keywords: bibisected, bisected, regression
: 127725 (view as bug list)
Depends on:
Blocks: Find&Replace-Dialog
  Show dependency treegraph
 
Reported: 2019-07-24 14:50 UTC by Stéphane Guillou (stragu)
Modified: 2020-10-22 12:39 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
new doc created with Writer (9.56 KB, application/vnd.oasis.opendocument.text)
2019-07-24 14:51 UTC, Stéphane Guillou (stragu)
Details
preexisting doc converted from RTF to ODT (9.72 KB, application/vnd.oasis.opendocument.text)
2019-07-24 14:52 UTC, Stéphane Guillou (stragu)
Details
extra indentation settings visible when only strikethrough format searched (46.56 KB, image/png)
2019-07-28 12:16 UTC, Stéphane Guillou (stragu)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stéphane Guillou (stragu) 2019-07-24 14:50:17 UTC
Description:
Using "Find and Replace > Format..." does not work in a new document, when looking for text formatted in a certain way. It does however work in other documents.

Steps to Reproduce:
1. Open attachment new_doc.odt (brand new document created with LibreOffice)
2. Find and Replace > Format... > Font Effects > Strikethrough > Single
3. Click "OK"
4. Click "Find all"

Actual Results:
The words that are strikethrough are not selected

Expected Results:
Nothing was found


Reproducible: Always


User Profile Reset: No



Additional Info:
The same steps done in preexisting_doc.odt work as expected for some reason.
This file used to be an RTF document, that had (possibly) been edited with Microsoft Office at some stage.

Not sure how to consistently create a document in which the format search will work.

Tested with:

Version: 6.2.5.2
Build ID: 1:6.2.5-0ubuntu0.18.04.1~lo1
CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: en-AU (en_AU.UTF-8); UI-Language: en-GB
Calc: threaded
Comment 1 Stéphane Guillou (stragu) 2019-07-24 14:51:24 UTC
Created attachment 152967 [details]
new doc created with Writer
Comment 2 Stéphane Guillou (stragu) 2019-07-24 14:52:09 UTC
Created attachment 152968 [details]
preexisting doc converted from RTF to ODT
Comment 3 m_a_riosv 2019-07-24 23:10:38 UTC
Works for me
Version: 6.2.5.2 (x64)
Build ID: 1ec314fa52f458adc18c4f025c545a4e8b22c159
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
Locale: es-ES (es_ES); UI-Language: en-US Calc: threaded
Comment 4 Stéphane Guillou (stragu) 2019-07-25 00:54:15 UTC
Very interesting! Thanks for testing, m.a.riosv

I should add that using the "Find & Replace > Attributes... > Strikethrough" works as expected in both documents.

I also just tried to restart in safe mode with user profile as factory settings, which didn't fix it.

I also noticed that, when selecting single strikethrough as the format searched for, we can see underneath the Find box:
"Single strikethrough, Indent left 0.0 inch, From top 0.0 inch, From bottom 0.0 inch"
Is that expected? It is confusing, as the search didn't specify any values for indentation.
Comment 5 Dieter 2019-07-26 05:03:36 UTC
I also couldn't reproduce with

Version: 6.2.5.2 (x64)
Build-ID: 1ec314fa52f458adc18c4f025c545a4e8b22c159
CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win; 
Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE
Calc: threaded

Perhaps only Linux?

But I also couldn't see the hints for intendation. Can you attach a screenshot of it?
Comment 6 Stéphane Guillou (stragu) 2019-07-28 12:16:18 UTC
Created attachment 153013 [details]
extra indentation settings visible when only strikethrough format searched

Here is a screenshot of what appears when I do a strikethrough format search.
The indentation settings are not expected.

This is not limited to strikethrough: anything I have tested from the options in "Format..." will add these 4 extra formatting options.
Comment 7 Dieter 2019-07-28 18:00:41 UTC
I confirm it with

Version: 6.4.0.0.alpha0+ (x64)
Build ID: 8f98a7c4e5b1f0b249c026577805a378b8a533d5
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-07-23_00:30:19
Locale: de-DE (de_DE); UI-Language: en-US
Calc: threaded

Additional informations to reproduce
If I only choose tab "Font Effects" and select "Strikethrough" everyghing is fine. If I click all the other tabs (without selecting anything) the fomatting "Orphan control 0 Lines, widow Control 0 Lines" is added.

Same result in

Version: 6.1.6.3 (x64)
Build-ID: 5896ab1714085361c45cf540f76f60673dd96a72
CPU-Threads: 4; BS: Windows 10.0; UI-Render: GL; 
Gebietsschema: de-DE (de_DE); Calc: group threaded

But not in

Version: 5.4.7.2 (x64)
Build-ID: c838ef25c16710f8838b1faec480ebba495259d0
CPU-Threads: 4; BS: Windows 6.19; UI-Render: GL; 
Gebietsschema: de-DE (de_DE); Calc: group
Comment 8 Stéphane Guillou (stragu) 2019-07-28 22:26:23 UTC
Hi Dieter

Just to be clear: you are confirming that unwanted format settings are added to the search, but:

- you get different extra formats to me, and
- the basic "Format... > Font Effects > Strikethrough > Single" search originally described in this report (with the example documents) does _not_ add the extra formatting; for extra formatting to appear, you need to navigate to the other tabs.

Is that right?

Do you think that my original strikethrough search fails because of those unwanted settings?

I just noticed that if I open the "Format..." dialogue and directly click "OK" without changing anything still adds the indentation formatting to the search.
Comment 9 Dieter 2019-07-29 10:49:46 UTC
(In reply to stragu from comment #8)
> Hi Dieter
> 
> Just to be clear: you are confirming that unwanted format settings are added
> to the search, but:
> 
> - you get different extra formats to me, and
> - the basic "Format... > Font Effects > Strikethrough > Single" search
> originally described in this report (with the example documents) does _not_
> add the extra formatting; for extra formatting to appear, you need to
> navigate to the other tabs.
> 
> Is that right?

Yes.

> 
> Do you think that my original strikethrough search fails because of those
> unwanted settings?

Yes

> 
> I just noticed that if I open the "Format..." dialogue and directly click
> "OK" without changing anything still adds the indentation formatting to the
> search.

O.K., that's seems to be different. But the problem, that additional formats are added, still remains. Let's see, if somebody can bibisect it.
Comment 10 Stéphane Guillou (stragu) 2019-07-29 12:45:31 UTC
I tested on another computer (running Linux Mint 18.2) and I can't reproduce with:

Version: 5.3.6.1
Build ID: 686f202eff87ef707079aeb7f485847613344eb7
CPU Threads: 4; OS Version: Linux 4.15; UI Render: default; VCL: gtk2; Layout Engine: new; 
Locale: en-AU (en_AU.UTF-8); Calc: group

Version: 6.2.6.1
Build ID: 1f09ad467b449704e317fb11998b9a2ad7184670
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: en-AU (en_AU.UTF-8); UI-Language: en-US
Calc: threaded

Version: 6.3.0.1
Build ID: 41ac97386aba908b6db860cfb4cfe2da871886ae
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: en-AU (en_AU.UTF-8); UI-Language: en-US
Calc: threaded

The strikethrough search works as expected (i.e. it doesn't add extra unwanted format options).

However, when I navigate to other format tabs, don't select anything and click "OK":
- 5.3 doesn't add anything (i.e. works as expected, just like 5.4 as reported by Dieter)
- 6.2 and 6.3 add a variety of unwanted "Kerning", "Orphan control", "Widow control", "Indent" and "From" format options to the search, depending on which tab was opened. (Behaviour that I can confirm on my other Ubuntu Budgie computer, the one I was using when I originally reported this bug.)

So, really, the only difference between my two computers is that, on Linux Mint, no extra useless formats are added when I don't change tabs, whereas on Ubuntu Budgie, the useless format settings are added _even_ if I don't change tabs.

It's as if the behaviour depends on the desktop environment doing some kind of refreshing of the format tab that is first opened, or not...
Comment 11 Stéphane Guillou (stragu) 2019-07-29 12:47:51 UTC
Sorry, my previous comment should really start with "can't reproduce _the original strikethrough issue_". The updated bug description of adding unwanted format settings is definitely reproducible on both 6.2 and 6.3.
Comment 12 raal 2019-09-19 08:19:37 UTC
(In reply to stragu from comment #10)
> 
> However, when I navigate to other format tabs, don't select anything and
> click "OK":
> - 5.3 doesn't add anything (i.e. works as expected, just like 5.4 as
> reported by Dieter)
> - 6.2 and 6.3 add a variety of unwanted "Kerning", "Orphan control", "Widow
> control", "Indent" and "From" format options to the search, depending on
> which tab was opened. (Behaviour that I can confirm on my other Ubuntu
> Budgie computer, the one I was using when I originally reported this bug.)
> 

This seems to have begun at the below commit.
Adding Cc: to Jim Raykowski; Could you possibly take a look at this one? Thanks
 62cf75d81d946525da55ed740082c10d45957ab7 is the first bad commit
commit 62cf75d81d946525da55ed740082c10d45957ab7
Author: Norbert Thiebaud <nthiebaud@gmail.com>
Date:   Fri Jan 26 00:35:42 2018 -0800

    source 122da2eea23faf6916c3f3b9e1895f5c404b26c7

author	Jim Raykowski <raykowj@gmail.com>	2017-11-18 22:21:24 -0900
committer	Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>	2018-01-26 08:10:20 +0100
commit 122da2eea23faf6916c3f3b9e1895f5c404b26c7 (patch)
tree 8e817bf22bb392d13c7b53948fc166da23579ce0
parent 674b67ab7d92097089000fcd70c7abd84e180220 (diff)
tdf#107567 et al. Paragraph dialog preview windows fixes
Comment 13 Jim Raykowski 2019-09-20 02:57:50 UTC
My guess is this started with commit eb1d6b16e787a87c3d918135ca98c5694d352557

Here is a patch that fixes the problem of Widow and Orphan control lines automatically added to the search when the Text Flow tab is visited.

https://gerrit.libreoffice.org/#/c/79265/
Comment 14 Commit Notification 2019-09-21 03:59:26 UTC
Jim Raykowski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/22dede7f65acb6b1f8c75647ecadd9acdcced287

tdf#126527 Fix widow and orphan lines being added to search

It will be available in 6.4.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.
Comment 15 Stéphane Guillou (stragu) 2019-09-23 23:13:55 UTC
Thank you, Jim! Will try to test that when I get time.

Any chance this is going to make it into 6.3?
Comment 16 Stéphane Guillou (stragu) 2019-10-22 13:39:53 UTC
Jim, I tested in 6.4 alpha 1, following the steps in comment 1, and it works as expected _only_ if I don't have to navigate through the "Text Flow" tab before selecting single strikethrough (i.e. the "Font Effects" tab is opened straight away when clicking the "Format..." button).

If I open the "Text Flow" tab, I get "Orphan control 0 Lines, Widow control 0 Lines," in the search criteria, which makes the search fail.

So my understanding is that the fix was partial? We still get unwanted search criteria added by simply opening the "Text Flow" tab. Other tabs don't add unwanted criteria anymore.

Tested with:

Version: 6.3.2.2
Build ID: 1:6.3.2-0ubuntu0.18.04.1~lo1
CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: en-AU (en_AU.UTF-8); UI-Language: en-GB
Calc: threaded
Comment 17 Jim Raykowski 2019-10-23 03:09:26 UTC
(In reply to stragu from comment #16)
> Jim, I tested in 6.4 alpha 1, following the steps in comment 1, and it works
> as expected _only_ if I don't have to navigate through the "Text Flow" tab
> before selecting single strikethrough (i.e. the "Font Effects" tab is opened
> straight away when clicking the "Format..." button).
> 

> Tested with:

> Version: 6.3.2.2
> Build ID: 1:6.3.2-0ubuntu0.18.04.1~lo1
> CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3; 
> Locale: en-AU (en_AU.UTF-8); UI-Language: en-GB
> Calc: threaded

Hi stragu,

Make sure you test with a version that has the patch merged. 

The AppImage version here includes the patch:
http://libreoffice.soluzioniopen.com/index.php/daily-version/

> Any chance this is going to make it into 6.3?

The QA team specializes in back porting. I just try to fix things without breaking things.
Comment 18 Dieter 2019-10-27 05:14:27 UTC
(In reply to Commit Notification from comment #14)
> Affected users are encouraged to test the fix and report feedback.

Looks fine in

Version: 6.4.0.0.alpha1 (x64)
Build ID: cc57df8f942f239d29cb575ea5a7cb01405db787
CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: GL; VCL: win; 
Locale: de-DE (de_DE); UI-Language: en-US
Calc: threaded

Jim, you haven't changed status to RESOLVED FIXED. So is there anything to do?
Comment 19 Jim Raykowski 2019-10-27 05:31:20 UTC
Dieter, 
I think there is nothing more to do here. I have set to resolved fixed. Thanks for reminding me.
Comment 20 Dieter 2019-10-27 05:35:17 UTC
(In reply to Dieter Praas from comment #18)
> Looks fine in
> 
> Version: 6.4.0.0.alpha1 (x64)
> Build ID: cc57df8f942f239d29cb575ea5a7cb01405db787
> CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: GL; VCL: win; 
> Locale: de-DE (de_DE); UI-Language: en-US
> Calc: threaded

=> VERIFIED FIXED

Thnaks for fixing it, Jim.
Comment 21 Stéphane Guillou (stragu) 2019-10-28 01:06:05 UTC
Thanks everyone. The appimage version worked fine, all good from my end too.
Cheers, Jim!
Comment 22 Alexis 2020-01-13 05:57:49 UTC
Confirmed fixed on my system.

Fantastic! The update works very well.
Comment 23 Dieter 2020-01-13 07:03:45 UTC
*** Bug 127725 has been marked as a duplicate of this bug. ***