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
Created attachment 161275 [details] Screencast
Step 9 Right click Graphic again
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
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.
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.
"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.
(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?
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.
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.
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.
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.
fixed in master, backport to 7-0 in gerrit
(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.
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.
*** Bug 133381 has been marked as a duplicate of this bug. ***
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
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.