Bug Hunting Session
Bug 124548 - Activating Area tab, "None" is always focused, regardless of which fill type is selected
Summary: Activating Area tab, "None" is always focused, regardless of which fill type ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
(earliest affected)
Hardware: All All
: medium normal
Assignee: Not Assigned
Keywords: difficultyBeginner, easyHack, skillCpp, topicUI
Depends on:
Blocks: Area-Fill-Tab
  Show dependency treegraph
Reported: 2019-04-04 14:07 UTC by Mike Kaganski
Modified: 2019-06-26 10:26 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

Screenshot of "None" selected when "Color" is active (92.39 KB, image/png)
2019-04-04 14:07 UTC, Mike Kaganski

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Kaganski 2019-04-04 14:07:29 UTC
Created attachment 150524 [details]
Screenshot of "None" selected when "Color" is active

Activating Area tab, "None" is always focused, regardless of which fill type is active.

Use e.g. these steps:

- Create a new Writer document;
- Format->Page;
- Click "Area" tab in the Page Style dialog.
=> "None" toggle button is both active (pushed) and focused (has a frame around it, indicating the current focus control).
- Click "Color" toggle button to set background to some color
- Click "Page" (or any other) tab to leave "Area" tab;
- Click "Area" tab to return.
=> "Color" toggle button is active (pushed); but "None" is focused. This creates a confusing impression of the two "active" modes; it's not always easy to tell which of the two distinct highlighted elements is really active: see the screenshot - on Windows 10, focusing makes the button so more emphasized than activating.

Upon activation of the "Area" tab, currently active button should be both pressed, and focused.

Code pointer: see SvxAreaTabPage::ActivatePage in cui/source/tabpages/tparea.cxx.
Comment 1 Durgapriyanka 2019-04-04 14:36:50 UTC
Thank you for reporting the bug. I can confirm the bug present in

Build ID: b6b28931435e44aca92b8c0e1659f701e3ed1a87
CPU threads: 2; OS: Windows 6.1; UI render: default; VCL: win; 
TinderBox: Win-x86@42, Branch:master, Time: 2019-01-30_06:57:04
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded
Comment 2 Jörg Schaffner 2019-04-30 10:39:20 UTC
I've tested this bug and my opinion is: it is not really a bug. The focus is set on NONE-Button always when entering the PAGE tab. This is OK.
The toggle-state of a button connected with the content below is a specific design decision with this issue as a draw back. An alternative would be to change this design (cascaded tab-component) - not really better - I think.
Comment 3 Mike Kaganski 2019-04-30 10:46:52 UTC
(In reply to Jörg Schaffner from comment #2)

Sigh. This is a bug, and it was evaluated, and its fix is easy. If you think that any "draw back" that you don't know how to fix is not possible, or not needed, to be fixed, it's wrong. No need to make large-scale changes. And no need to say "oh that's unfortunate result of decision to use that control, and we need not to try to improve that control behavior".
Comment 4 Jörg Schaffner 2019-04-30 11:03:59 UTC
Sorry for my opinion - I do not want to start a discussion here. But think about the following: the focus of a button is not an indicator for his toggle state.

And generally: every design decisions has advantages and draw backs. Draw backs are note automatically bugs.