https://bugs.documentfoundation.org/show_bug.cgi?id=170879
Bug ID: 170879
Summary: SfxTabPage::GetRanges() does not declare all WhichIds
actually handled by tab pages
Product: LibreOffice
Version: 3.3.0 release
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: framework
Assignee: [email protected]
Reporter: [email protected]
While working on tdf#89826 (interactive property chips for the style dialog
Organizer tab), I needed a reliable way to map a WhichId to the tab page that
handles it. The only existing mechanism is SfxTabPage::GetRanges(), which
returns ranges of SlotIds that each tab page declares it handles.
However, investigation revealed that GetRanges() is incomplete for several tab
pages. Some properties are read/written directly in Reset() / FillItemSet()
using explicit rSet->Get(nWhich) calls without the corresponding SlotId being
declared in GetRanges().
Example:
RES_CHRATR_HIGHLIGHT (WhichId 42) is handled by the Highlighting tab in
paragraph style page in its Reset() and FillItemSet() methods, but its
corresponding SlotId is not included in that tab page's GetRanges(). As a
result, any code that iterates tab pages and checks GetRanges() to find which
tab owns a given WhichId will fail to find a match for this property.
Root cause:
GetRanges() was originally designed to tell the framework which items to
include when building the filtered SfxItemSet passed to each tab page. Over
time, developers added item handling in Reset() / FillItemSet() without
updating GetRanges(), because:
- GetRanges() is a static method: it has no access to the instance, making it
easy to overlook;
- The items were still accessible via direct Get(nWhich) on the full item set,
so the missing declaration caused no visible breakage
- GetRanges() uses SlotId ranges, not WhichId ranges, and the SlotId↔WhichId
mapping is not always straightforward, which may have discouraged maintenance.
Impact:
Any code that needs to determine which tab page is responsible for a given
property cannot do so reliably. This affects:
- The new property chips feature (tdf#89826), which groups chips by tab page
- Any future feature that needs to map properties to their UI location
- Potentially the existing SfxTabDialogController item filtering, where items
might not reach the tab page that handles them
Proposed solution:
Audit all SfxTabPage subclasses (in cui/source/tabpages/, sw/source/ui/,
sc/source/ui/, sd/source/ui/) and ensure that every WhichId read in Reset() or
written in FillItemSet() has its corresponding SlotId declared in GetRanges().
This could be done incrementally, module by module.
Alternatively, consider introducing a new virtual method alongside GetRanges():
cppvirtual WhichRangesContainer GetHandledWhichIds() const;
that returns WhichId ranges directly and can be overridden per-instance,
providing a more reliable mapping. This would be a larger architectural change
but would solve the problem at its root.
Steps to reproduce (for verification):
- Open Writer, create a paragraph style with a parent style
- In the child style, modify the character highlighting color
- Build LibreOffice with SAL_INFO logging in
SfxTabDialogController::GetTabPageNameForWhich()
- Open the style dialog Organizer tab — the highlighting property cannot be
mapped to any tab page via GetRanges()
--
You are receiving this mail because:
You are the assignee for the bug.
