Bug Hunting Session
Bug 122943 - Opening a Style dialog's Highlighting/Area tabs adds properties to the property set in the style
Summary: Opening a Style dialog's Highlighting/Area tabs adds properties to the proper...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.3.0.3 release
Hardware: All All
: medium normal
Assignee: Jim Raykowski
URL:
Whiteboard: target:6.3.0
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Paragraph-Dialog
  Show dependency treegraph
 
Reported: 2019-01-25 06:50 UTC by Mike Kaganski
Modified: 2019-05-07 02:52 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Kaganski 2019-01-25 06:50:51 UTC
Create new text document; open Styles pane (F11) on Paragraph Styles; right-click "Frame Contents"->Modify...; check that Organizer tab has nothing under "Contains"; switch to Highlighting tab; switch back to Organizer tab and see that "Automatic, Transparent" is shown under "Contains". Switching to Area and back to Organizer tab adds "None" to "Contains".

Impact: this bug means that simply visiting the said tabs (without modifying the settings there) adds explicit corresponding values to the style definition; it's impossible to remove these definitions without cancelling the dialog. If user overlooks the change (which is most likely), and presses Apply/OK (e.g., to save changes made on other tabs), then it's totally impossible to get rid of the settings in the style later. Having the explicit settings in the style means that the style doesn't inherit these settings from parent, thus breaking normal (expected) inheritance of unset settings (user cannot set parent's Area later and have all child styles have that Area).

The problem with Area tab started at https://git.libreoffice.org/core/+/4c5079791f5d985151ebc090c5a07705e76a728e, *after* the tab already was replaced with new color tab. The problem with Highlighting is present in 6.2.0.2, but I cannot bibisect it, since the latest in bibisect-win32-6.2 doesn't have it, and the oldest in bibisect-win32-6.3 already has it; but it's likely connected with the changes made in bug 105225 moving to the new color pages.
Comment 1 Jim Raykowski 2019-01-27 02:06:20 UTC
Hi Mike,

The Alignment and Border tabs also do this. Alignment tab blame is mine.

https://gerrit.libreoffice.org/#/c/45273/

The old highlighting tab page also has this bug. Version 5.1.6.2 adds White, Transparent to Organizer Contains. Maybe it was corrected in later versions.

Moving this to top of the list of things to fix.
Comment 2 Jim Raykowski 2019-01-27 02:32:05 UTC
Just saw the border tab has been fixed. Will look at patches made for other see also bugs to apply to my effort.

Strange, I can't repro this for any of the tabs using current master build.

Version: 6.3.0.0.alpha0+
Build ID: bf359d01ac8b1e0292e8a92c38e58c03e6c17d8b
CPU threads: 4; OS: Linux 4.18; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded
Comment 3 Mike Kaganski 2019-01-28 07:05:59 UTC
(In reply to Jim Raykowski from comment #2)
> Strange, I can't repro this for any of the tabs using current master build.

Just tested with master build 3c2cd4829229a312e79cfba3971b954bd605681c, and I can repro with Highlighting/Area tabs. The Alignment and Border tabs were fixed by Caolán in bug 122914.

In some cases, the reproducibility of the problem could depend on used units (so that some chosen units could roundtrip values accurately, so the problem could get unnoticed) - bit as for Area's None section, this is not the case, and it should be reproducible always, since the mentioned commit puts the property into the set unconditionally.
Comment 4 Jim Raykowski 2019-01-29 06:36:12 UTC
Hi Mike,

Pulled and built the most recent master on a machine with GTK3 and a machine with GTK2.

I get different results between GTK3 and GTK2 when doing the steps below:  

Open writer after --safe-mode and reset to factory settings
Open Styles panel/deck in Sidebar
Right click 'Frames Contents' and select Modify
Paragraph Style:Frame Contents tab dialog appears with Organizer tab selected and 'Contains' area is blank
Click on Highlighting tab
Click back on Organizer tab
GTK3 results 'Contains' is still blank
GTK2 results 'Contains' shows Automatic,Transparent
Click on Area tab
Click back on Organizer tab
GTK3 results 'Contains' is still blank
GTK2 results 'Contains' show Automatic,Transparent+None

I think the difference is explained by GTK3 tab dialog not selecting the Area/Background tab page None button when the tab is activated. GTK2 selects the  None button when Area/Background tab page is activated. 

Regardless of the difference I am working on only setting attribs if set by user.
Comment 5 Mike Kaganski 2019-01-29 06:44:51 UTC
(In reply to Jim Raykowski from comment #4)
> I think the difference is explained by GTK3 tab dialog not selecting the
> Area/Background tab page None button when the tab is activated. GTK2 selects
> the  None button when Area/Background tab page is activated. 

Oh - I see. I use Windows, so wasn't aware of those peculiarities. So I'd consider GTK3 behavior wrong, since selecting of current option (even if inherited) must be done for each property, to tell user what the style will look like.
Comment 6 Jim Raykowski 2019-01-31 02:50:29 UTC
Hi Mike,

Having fun with the styles code. I've implemented some ideas how not to have the Area and Highlighting tabs add their None page attribs when no change has been made. Nothing so far that is very satisfying. WIP

There seems to be some love needed not for just the Area and Highlighting tabs use in the Paragraph Styles tab dialog. I noticed in order to add Left/Top alignment one must first select an alignment other than Left/Top, click on the Organizer tab, click back on the Alignment tab, and select Left/Top. Other tabs pages must follow this procedure to add defaults. In the Indents & Spacing tab, Line Spacing is not able to be added to a style. Checking Register-True Active check box adds Register-true but unchecking does not clear it. Same with check boxes in other tab pages.

Why isn't Default Style created from tab page defaults?
Comment 7 Jim Raykowski 2019-03-20 05:58:32 UTC
Here is a link to a patch that prevents the Area and Highlighting tab pages None fill properties from being added to a style without actually clicking on the None fill button. 

https://gerrit.libreoffice.org/#/c/69455/

Review and comments greatly appreciated.
Comment 8 Commit Notification 2019-03-20 12:21:20 UTC
Jim Raykowski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/2761709acf77b1f64d76d5828d09ad9e7d9dc4cb%5E%21

tdf#122943 Don't add properties to style when Highlighting and Area

It will be available in 6.3.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.