| Summary: | Infinite recursion in ImplBorderWindow::Resize when showing "Convert Text to Table" dialog in German UI | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | Stephan Bergmann <sberg.fun> |
| Component: | UI | Assignee: | Caolán McNamara <caolan.mcnamara> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | caolan.mcnamara |
| Priority: | medium | ||
| Version: | 7.3.0.0 alpha0+ | ||
| Hardware: | All | ||
| OS: | macOS (All) | ||
| See Also: | https://bugs.documentfoundation.org/show_bug.cgi?id=149273 | ||
| Whiteboard: | target:7.3.0 | ||
| Crash report or crash signature: | Regression By: | ||
| Bug Depends on: | |||
| Bug Blocks: | 102019 | ||
| Attachments: |
screenshot of dialog with English UI
screenshot of dialog with German UI |
||
|
Description
Stephan Bergmann
2021-09-01 11:58:00 UTC
we have this condition
if (nOrigLeftBorder != mnLeftBorder ||
nOrigTopBorder != mnTopBorder ||
nOrigRightBorder != mnRightBorder ||
nOrigBottomBorder != mnBottomBorder)
{
pCtrl->queue_resize();
}
which must be true on each recursive attempt through ImplSmallBorderWindowView::Init for some reason
The bisected commit presumably has affected the width of the widget "othered" in sw/uiconfig/swriter/ui/converttexttable.ui which has <property name="width_chars">1</property> <property name="max_width_chars">1</property> hacking those to, say, 5 might workaround the problem to see if its an overly narrow vcl Edit which is causing the problem Created attachment 174697 [details]
screenshot of dialog with English UI
Created attachment 174698 [details]
screenshot of dialog with German UI
One difference I notice (with the problematic f72013ca65c7a33991d5fb124b919fe7cde269e2 temporarily reverted) is that with German UI the "Other" (i.e., "Sonstige") edit box is narrower (see attachment 174698 [details]) than with the English UI (see attachment 174697 [details]). (In reply to Caolán McNamara from comment #2) > The bisected commit presumably has affected the width of the widget > "othered" in sw/uiconfig/swriter/ui/converttexttable.ui which has > > <property name="width_chars">1</property> > <property name="max_width_chars">1</property> > > hacking those to, say, 5 might workaround the problem to see if its an > overly narrow vcl Edit which is causing the problem yes, that change makes the crash go away Seems this is not the first time this has arisen: https://cgit.freedesktop.org/libreoffice/core/commit/?id=27be8a263eddb54cb6b66cc0f832bfd02016a694 Initial hackery seems to date to bug#57090 Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/905d7e3d9cff386a819faa6582cfb1700b529e34 tdf#144241 don't return a negative width for osx edit region It will be available in 7.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. That should do it |