Bug 137511 - [Calc] [UI] Crash when dragging sheet name into input name with touch screen
Summary: [Calc] [UI] Crash when dragging sheet name into input name with touch screen
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.3.0.3 release
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisectNotNeeded, regression
Depends on:
Blocks: Sheet-Tabs-Bar Drag-and-Drop Crash
  Show dependency treegraph
 
Reported: 2020-10-15 18:58 UTC by doomsdayrs
Modified: 2024-07-24 05:52 UTC (History)
5 users (show)

See Also:
Crash report or crash signature: ["libc.so.6","libgobject-2.0.so.0.7200.4"]


Attachments
BackTrace (11.02 KB, text/x-log)
2020-10-17 19:59 UTC, doomsdayrs
Details
GDB trace of assertion crash (7.51 KB, text/plain)
2023-02-24 15:14 UTC, Buovjaga
Details

Note You need to log in before you can comment on or make changes to this bug.
Description doomsdayrs 2020-10-15 18:58:01 UTC
Description:
A crash occurs when the user drags a "Sheet tab" from below the sheet into the "Input Line" above the sheet

Steps to Reproduce:
1. Have any spreadsheet
2. Drag the Sheet Tab on the bottom into the "Input Line"

Actual Results:
Crash instantly.

Expected Results:
1. Either error stating one cannot do such an action
or
2. Place sheet name as text content


Reproducible: Always


User Profile Reset: No


OpenGL enabled: Yes

Additional Info:
Version: 6.4.6.2
Build ID: 1:6.4.6-0ubuntu0.20.04.1
CPU threads: 12; OS: Linux 5.4; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded
Comment 1 Xisco Faulí 2020-10-15 19:48:40 UTC
Not reproducible in

Version: 7.1.0.0.alpha0+
Build ID: e897fdc46b07f211c4c96de103cfa494b645035a
CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

Does it happen with a particular file ? if so, could you please attach it ?
Comment 2 m_a_riosv 2020-10-15 21:04:37 UTC
Don't crash for me.
Version: 7.1.0.0.alpha0+ (x64)
Build ID: c064766901722082df0d759c95434c1460fcdba5
CPU threads: 4; OS: Windows 10.0 Build 20180; UI render: Skia/Vulkan; VCL: win
Locale: es-ES (es_ES); UI: en-US
Calc: CL
Comment 3 doomsdayrs 2020-10-15 23:31:55 UTC
(In reply to Xisco Faulí from comment #1)
> Not reproducible in
> 
> Version: 7.1.0.0.alpha0+
> Build ID: e897fdc46b07f211c4c96de103cfa494b645035a
> CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3
> Locale: en-US (en_US.UTF-8); UI: en-US
> Calc: threaded
> 
> Does it happen with a particular file ? if so, could you please attach it ?

Nope, I have also opened up Calc to a clean sheet, dragged the tab and it crashes
Comment 4 QA Administrators 2020-10-16 04:29:33 UTC Comment hidden (obsolete)
Comment 5 Xisco Faulí 2020-10-16 08:03:49 UTC
To be certain the reported issue is not related to corruption in the user profile, could you please reset your Libreoffice profile ( https://wiki.documentfoundation.org/UserProfile ) and re-test?

I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the issue is still present
Comment 6 doomsdayrs 2020-10-16 15:13:43 UTC
(In reply to Xisco Faulí from comment #5)
> To be certain the reported issue is not related to corruption in the user
> profile, could you please reset your Libreoffice profile (
> https://wiki.documentfoundation.org/UserProfile ) and re-test?
> 
> I have set the bug's status to 'NEEDINFO'. Please change it back to
> 'UNCONFIRMED' if the issue is still present

Running Calc in safemode produces the same results. An instant crash.
Comment 7 Julien Nabet 2020-10-17 09:27:00 UTC
On pc Debian x86-64 with master sources updated today + gtk3, I don't reproduce this.
Would it be possible you attach a screencast?
Perhaps we're missing something.
Also, if you still reproduce this, would it be possible you attach a stacktrace?
(see https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU.2FLinux:_How_to_get_a_backtrace)
Comment 8 doomsdayrs 2020-10-17 19:59:24 UTC
Created attachment 166472 [details]
BackTrace
Comment 9 doomsdayrs 2020-10-17 19:59:42 UTC
(In reply to Julien Nabet from comment #7)
> On pc Debian x86-64 with master sources updated today + gtk3, I don't
> reproduce this.
> Would it be possible you attach a screencast?
> Perhaps we're missing something.
> Also, if you still reproduce this, would it be possible you attach a
> stacktrace?
> (see
> https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU.
> 2FLinux:_How_to_get_a_backtrace)

There is the backtrace
Comment 10 Julien Nabet 2020-10-17 20:07:39 UTC
Thank you for your feedback.
=> let's put it back to UNCONFIRMED since I don't have more questions.
I must recognize I'm a bit stuck here.
Uncc myself since I can't help.
Comment 11 raal 2020-12-30 00:48:57 UTC
I can not confirm with Version: 7.2.0.0.alpha0+
Build ID: 2577d9ecea199ca2c10d852cf279053a1b22faf7
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3
Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US
Calc: threaded
Comment 12 Xisco Faulí 2021-07-07 10:59:43 UTC
Hello,
Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ?
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
Comment 13 QA Administrators 2022-01-04 03:30:48 UTC Comment hidden (obsolete)
Comment 14 doomsdayrs 2022-01-05 00:55:49 UTC
As of Office 7.2.41, This bug has changed.

On Desktop, I can drag the sheet name into the "Input Line" without any errors using the mouse.

On my laptop, If I attempt to do the same with the touch screen, Calc crashes the moment the drag begins.
Comment 15 Buovjaga 2023-02-24 15:07:41 UTC
(In reply to doomsdayrs from comment #14)
> As of Office 7.2.41, This bug has changed.
> 
> On Desktop, I can drag the sheet name into the "Input Line" without any
> errors using the mouse.
> 
> On my laptop, If I attempt to do the same with the touch screen, Calc
> crashes the moment the drag begins.

Do you mean it used to crash on the desktop with mouse as well?

On your laptop, does it make a difference, if you change the UI by launching from the terminal with

SAL_USE_VCLPLUGIN=gen libreoffice
SAL_USE_VCLPLUGIN=kf5 libreoffice
Comment 16 Buovjaga 2023-02-24 15:14:05 UTC
Created attachment 185572 [details]
GDB trace of assertion crash

With a debug build, I get an assertion:
soffice.bin: /home/user/libreoffice/editeng/source/editeng/impedit2.cxx:3350: sal_uInt32 ImpEditEngine::GetTextHeight() const: Assertion `IsUpdateLayout() && "Should not be used for Update=FALSE: GetTextHeight"' failed.

I get it with gtk3 and gen, but not kf5. I guess we could set to NEW.
Comment 17 Stéphane Guillou (stragu) 2024-07-24 04:57:04 UTC
Note about the original focus of this bug:

Drag-and-drop of empty sheet into field that accepts text used to crash/freeze with gtk2/3 VCL, since 5.3 all the way to 6.4. Not reproduced in 5.2.0.4.

Version: 6.0.0.3
Build ID: 64a0f66915f38c6217de274f0aa8e15618924765
CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk2; 
Locale: en-AU (en_AU.UTF-8); Calc: group

See e.g. https://crashreport.libreoffice.org/stats/crash_details/46c84616-acfe-401c-8782-43389bbad06c and https://crashreport.libreoffice.org/stats/crash_details/4419e2c1-01f8-43f9-b734-3b03112e6058

However, that was resolved in 7.0.0.3.

Leaving this open for the touch screen / assert issue, but as the original issue lives on in current master for gen VCL plugin, I opened bug 162166.
I suspect it started at the same commit:

commit 432b27ec73940738bb0b4f9d3d749c70a2525700
author	Pranav Kant	Fri Jun 03 00:46:48 2016 +0530
committer	Pranav Kant	Fri Jun 03 00:55:41 2016 +0530
sc: Don't export in case of invalid range
Comment 18 Stéphane Guillou (stragu) 2024-07-24 05:52:59 UTC
(In reply to Stéphane Guillou (stragu) from comment #17)
> However, that was resolved in 7.0.0.3.
The issue being resolved for gtk3 was a side-effect of Caolán's welding effort. For example, if drag-and-dropping into the Name Box, fixed by:

commit 6407eb952efae074850c4e8c52c630397914a145
author	Caolán McNamara Mon Feb 17 10:49:59 2020 +0000
committer	Caolán McNamara Mon Feb 17 13:39:58 2020 
weld ScPosWnd Item Window

Other targets would have had a fix at other times.