Download it now!
Bug 133385 - Crash/fatal error when following sequence of steps in the style dialog
Summary: Crash/fatal error when following sequence of steps in the style dialog
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.0.0.0.alpha1+
Hardware: All All
: medium normal
Assignee: Caolán McNamara
URL:
Whiteboard: target:7.0.0 target:7.0.0.1
Keywords: bibisectRequest, haveBacktrace, regression
: 133381 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-05-25 18:32 UTC by Telesto
Modified: 2020-05-28 13:22 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Screencast (614.58 KB, video/mp4)
2020-05-25 18:33 UTC, Telesto
Details
bt with debug symbols (gen) (9.22 KB, text/plain)
2020-05-26 06:36 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2020-05-25 18:32:47 UTC
Description:
Crash/fatal error when following sequence of steps in the style dialog

Steps to Reproduce:
1. Open Writer
2. Sidebar -> Styles
3. Frame tab 
4. Right click Graphic -> Modify
5. Press apply & OK
6. Tab switches to Paragraph
7. Go to frame again
8. Right click Graphic/modify


Actual Results:
Crash/fatal error

Expected Results:
No crash/fatal error


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.0.0.0.alpha1+ (x64)
Build ID: b587de60d4e6aa96238766272d94f1499b22f696
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win; 
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL

not in 6.0
Comment 1 Telesto 2020-05-25 18:33:30 UTC
Created attachment 161275 [details]
Screencast
Comment 2 Telesto 2020-05-25 18:33:51 UTC
Step 9 Right click Graphic again
Comment 3 Tamas Tardos 2020-05-25 19:39:16 UTC
I can reproduce the crash with the 8 steps using:
Version: 7.0.0.0.alpha1+ (x64)
Build ID: 21875558f6c478f07d68ff39e025d7ffd451674f
CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: Skia/Raster; VCL: win
Locale: hu-HU (hu_HU); UI: en-US
Calc: threaded
https://crashreport.libreoffice.org/stats/crash_details/3ba4d16b-eb91-460a-a165-31459731c6e5
Comment 4 Julien Nabet 2020-05-26 06:36:11 UTC
Created attachment 161290 [details]
bt with debug symbols (gen)

On pc Debian x86-64 with master sources updated today + gen rendering, I could reproduce this.
Comment 5 Julien Nabet 2020-05-26 06:41:05 UTC
Several remarks:
1) with gen rendering, it's weird that once you click Ok, LO goes back automatically to paragraph styles instead of staying on frames styles

2) with gtk3 rendering, I don't reproduce the crash but if I right click on graphic entry in frames styles, first time, I only see "New" enabled, I must right click again to see "Modify" enabled.

Perhaps all issues are related. If it's not the case, new bugtrackers may be created.

Caolán: thought you might be interested in this one.
Comment 6 Caolán McNamara 2020-05-27 13:51:31 UTC
"it's weird that once you click Ok, LO goes back automatically to paragraph styles instead of staying on frames styles"

I think this is (sort of) by design. Start writer, have navigator visible, insert a frame, the frame should be automatically selected. Wait a sec or two, and the frame category is auto-opened in the navigator, click in main text, wait a moment, and it goes back to the paragraph category. click on frame, and frame category auto-opened.

so in the case described in this bug the styles are updated and the same sort of auto-open takes place, causing the navigator to go back to paragraphs automatically.

I'm not sure how much of a good idea this behaviour is but I'm not touching it :-)

sw/source/uibase/app/docst.cxx the case SID_STYLE_FAMILY3: and there rSet.Put(SfxTemplateItem(nWhich, aName)) is only done if there is a pFormat, but for the other style families a SfxTemplateItem is always inserted, with a blank name if there is none.
Comment 7 Julien Nabet 2020-05-27 14:00:04 UTC
(In reply to Caolán McNamara from comment #6)
> "it's weird that once you click Ok, LO goes back automatically to paragraph
> styles instead of staying on frames styles"
> 
> I think this is (sort of) by design. Start writer, have navigator visible,
> insert a frame, the frame should be automatically selected. Wait a sec or
> two, and the frame category is auto-opened in the navigator, click in main
> text, wait a moment, and it goes back to the paragraph category. click on
> frame, and frame category auto-opened.
> 
> so in the case described in this bug the styles are updated and the same
> sort of auto-open takes place, causing the navigator to go back to
> paragraphs automatically.
> 
> I'm not sure how much of a good idea this behaviour is but I'm not touching
> it :-)
>...
Xisco/Heiko: just to confirm, is it expected from UI point of view?
Comment 8 Heiko Tietze 2020-05-27 15:28:30 UTC
Think it's a consequence of Jim's work on the Navigator. With 6.3 you stay at the frame tab but no item is selected and the cursor is not going back to the document. In 7.0 your cursor is placed where it was before and you can continue to type- plus the current PS is highlighted. I imagine that starting the same from a frame has a similar effect. 

So yes, it's by design for sake of accessibility.
Comment 9 Commit Notification 2020-05-27 15:32:39 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/bcbbd77f42ac03bbe9d0754051b72e0faed20b11

Related: tdf#133385 set cursor in row on right click

It will be available in 7.0.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.
Comment 10 Caolán McNamara 2020-05-27 15:35:16 UTC
Re comment #8 I think it precedes those changes. I think I've now hopelessly muddied the waters by using the word "navigator" when I mean the styles pane. Anyhow the crash is the substantive thing to hand here.
Comment 11 Commit Notification 2020-05-27 15:42:31 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/c0851e6306ed1117130d8667e22cfae8d0ee7e53

Resolves: tdf#133385 dangling pTargetEntry after remove or clear

It will be available in 7.0.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.
Comment 12 Caolán McNamara 2020-05-27 15:43:12 UTC
fixed in master, backport to 7-0 in gerrit
Comment 13 Heiko Tietze 2020-05-27 15:50:11 UTC
(In reply to Caolán McNamara from comment #10)
> muddied the waters by using the word "navigator"

It was me mistakenly speaking about the wrong deck. Point is that a11y requires the cursor to go back to the document after modification. Thanks for the patch.
Comment 14 Commit Notification 2020-05-27 19:26:56 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-7-0":

https://git.libreoffice.org/core/commit/4bdbb29a6b8d605d2a5fec1d080d386a95c183be

Related: tdf#133385 set cursor in row on right click

It will be available in 7.0.0.1.

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.
Comment 15 Telesto 2020-05-28 08:00:22 UTC
*** Bug 133381 has been marked as a duplicate of this bug. ***
Comment 16 Telesto 2020-05-28 08:01:34 UTC
Working as expected!
Version: 7.1.0.0.alpha0+ (x64)
Build ID: 41d8b41767032681a9897b7551f011d450e3725e
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL
Comment 17 Commit Notification 2020-05-28 13:22:19 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-7-0":

https://git.libreoffice.org/core/commit/775a205a334659c124c02272edd81a01af69cf47

Resolves: tdf#133385 dangling pTargetEntry after remove or clear

It will be available in 7.0.0.1.

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.