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.
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.
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
(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.
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.
(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.
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?
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.
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.