Description: If you copy some text and decide to paste it as unformatted text, while text in at least two bullets (points) is selected... it will cause LibreOffice Impress to hang, i.e. not respond. I attached working presentation. In my case, it happens every single time. Steps to Reproduce: 1. Open the presentation from attachment 2. Go to the first slide and copy the text in text-box 3. Go to the second slide 4. Select text in two bullets (you can also select all text, but don't select only first bullet) 5. Go to Paste Special -> Unformatted Text Actual Results: LibreOffice is not responding. Force Quit is the only solution to this problem. Expected Results: Existing two bullets are replaced with the text from clipboard, keeping formatting from the second slide. Reproducible: Always User Profile Reset: No Additional Info: [Information automatically included from LibreOffice] Locale: en-US Module: PresentationDocument [Information guessed from browser] OS: Linux (All) OS is 64bit: yes User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36
Created attachment 139570 [details] working file
No problem on macOS with Version: 5.4.4.5 Build ID: 2524958677847fb3bb44820e40380acbe820f960 CPU threads: 4; OS: Mac OS X 10.13.3; UI render: default; Locale: de-DE (de_DE.UTF-8); Calc: group and Version: 6.1.0.0.alpha0+ Build ID: 01f59d11df3d08c00bb53c093f16b924b7fdd1d9 CPU threads: 4; OS: Mac OS X 10.13.3; UI render: default; Locale: de-DE (de_DE.UTF-8); Calc: group threaded
just additional information, this is the output from termina: "(soffice:17279): GLib-GObject-WARNING **: /build/glib2.0-prJhLS/glib2.0-2.48.2/./gobject/gsignal.c:3486: signal name 'selection_changed' is invalid for instance '0x32fd9b0' of type 'OOoAtkObjCompTxt'"
Confirmed on ubuntu 16.04 x64 with Version: 6.1.0.0.alpha0+ Build ID: c7f74bbab4c666a8b3b865dbd58b3666f1f63052 CPU threads: 2; OS: Linux 4.4; UI render: default; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2018-02-03_00:22:13 Locale: en-US (en_US.UTF-8); Calc: Unconfirmed with Version: 6.0.0.0.alpha1+ Build ID: 637d96a25926e299fff5b4cf5a0055b1d171b23b CPU threads: 2; OS: Linux 4.4; UI render: default; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-11-17_23:45:59 Locale: en-US (en_US.UTF-8); Calc: single Unconfirmed on windows 7 x64 with Version: 6.0.0.3 Build ID: 64a0f66915f38c6217de274f0aa8e15618924765 CPU threads: 3; OS: Windows 6.1; UI render: default
Regression introduced by: author Armin Le Grand <Armin.Le.Grand@cib.de> 2017-08-10 20:08:56 +0200 committer Armin Le Grand <Armin.Le.Grand@cib.de> 2017-08-11 08:51:43 +0200 commit 5131f5ba19ebc5de17139dbcf373866a9b155b2b (patch) tree 627beb6b4b636e0161ba92ecf7fc3005a2c3b983 parent 46b4eb8b0e9325f8c29cd391baf9504bccee1837 (diff) editviewoverlay: corrected AttributeChange EditView on Overlay visualization needs to handle selection change when e.g. FontSize attribute of a selected text portion changes. Changed handling so that selection overlay is an integral part of text visualization overlay and refreshing text visualization always refreshes selection visuals, but not the other way around. Both anyways check for real change, so just extra testing is avoided which is still the better solution Bisected with: bibisect-linux64-6.0 Adding Cc: to Armin Le Grand
With the dbgutil enabled build of: Version: 6.0.0.0.alpha1+ Build ID: 6070dec9ca9a15587a2aece81f9ae1ab5ac0f8c4 CPU threads: 2; OS: Linux 4.14; UI render: default; VCL: gtk3; Locale: zh-CN (zh_CN.UTF-8); Calc: group At the time of step 5： 1. When run without --backtrace, , I get millions of: warn:editeng:9345:9345:editeng/source/editeng/impedit.cxx:285: Portion in Selection not found! warn:editeng:9345:9345:editeng/source/editeng/impedit.cxx:285: Portion in Selection not found! ... 2. When run with --backtrace, I get millions of: warn:legacy.tools:9749:9749:editeng/source/editeng/impedit.cxx:362: DrawSelectionXOR, Start >= End? warn:legacy.tools:9749:9749:editeng/source/editeng/impedit.cxx:362: DrawSelectionXOR, Start >= End? ... See backtrace.
Created attachment 139784 [details] gdbtrace.log (source-hash-6070dec9ca9a15) This gdbtrace.log was generated using the dbgutil daily build with source-hash-6070dec9ca9a15.
This bug does not happen with the new 6.0.1.1 release, if I do not enable GL (the default). However, when I manually enable GL in 6.0.1.1 on my machine, the UI is not responding when I am trying to select the text on the 2nd slide, no matter whether I copied text from 1st slide or not.
I found another hang caused by the same commit which is reproducible on Linux but not on Win STR: 1. Open Impress 2. Insert a table 3. Add some text to A1 4. Select the text with Ctrl + A 5. Paste the text in A2 3 times 6. Undo 4 times -> LibreOffice hangs Version: 6.1.0.0.alpha0+ Build ID: 234d0368c823eb1a74e973e051ac522e6b86e833 CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk2; Locale: ca-ES (ca_ES.UTF-8); Calc: group Reproduced with GTK and GTK3 but not with GEN @Caolán, I thought you might be interested in this one...
The same problem appears in LibreOffice Draw when you use TextBox with some text (two or more bullets) and you want to paste unformatted text.
*** Bug 117619 has been marked as a duplicate of this bug. ***
Current master: Do not get a hang at all. Used undo/redo whole stack. How to exactly and reliably create a crash/hang..?
(In reply to Armin Le Grand (CIB) from comment #12) > Current master: Do not get a hang at all. Used undo/redo whole stack. > > How to exactly and reliably create a crash/hang..? Hi Armin, I can still reproduce the steps from comment 9 in Version: 6.1.0.0.beta1+ Build ID: 8b96445766efe237eb47608ade6c147673466e2e CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded
Regarding the steps in the description, I can no longer reproduce them in Version: 6.2.0.0.alpha0+ Build ID: 48b49937fed5e50d299a94063eb325799ff672e9 CPU threads: 1; OS: Windows 6.1; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2018-06-05_01:47:06 Locale: es-ES (es_ES); Calc: group threaded but I can in Version: 6.1.0.0.beta1+ Build ID: 8b96445766efe237eb47608ade6c147673466e2e CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded so it seems it's linux only!!!
I haven't checked these steps, but I can repro the hang with the steps from bug 117619. Version: 6.2.0.0.alpha0+ Build ID: bdf5a7b5792cc93cd0a8984cfd8528dfe67b3e70 CPU threads: 16; OS: Linux 4.13; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); Calc: group threaded
This bug can be reproduced on windows, if you have a screen reader running and enabled it in the settings. On linux this option is turned on by default. I haven't tested it on MacOS, but I would assume it can be reproduced there too.
Paul Trojahn committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=65eaebd2879c18926d4672c9276ef7f73f87af99 tdf#115438 Fix freeze when pasting unformatted text It will be available in 6.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I do confirm the steps in comment 0 are fixed in Version: 6.2.0.0.alpha0+ Build ID: aa84f1458f422c1acf38b53a3e3138cd0e84e313 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded However, the steps in comment 9 are still reproducible... I will create a follow-up bug for that... @Paul Trojahn, Thanks for fixing this! Should it be backported to 6-1 and 6-0 branches ?
There already is a patch for 6-1: https://gerrit.libreoffice.org/#/c/58136/2 I think this has a pretty low risk of causing any regressions. @Caolán McNamara Is there a reason you only created a patch for 6-1? I'll see if I can fix the follow-up.
Paul Trojahn committed a patch related to this issue. It has been pushed to "libreoffice-6-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=19d6d196c9bc70f7a5938c89830b57dbdcfb8801&h=libreoffice-6-1 tdf#115438 Fix freeze when pasting unformatted text It will be available in 6.1.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
no specific reason not to do it for 6-0 I guess, so available as https://gerrit.libreoffice.org/#/c/58218/
Paul Trojahn committed a patch related to this issue. It has been pushed to "libreoffice-6-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c47d8e5fc91fa3f067eb4955fd5bd27cbffd5d51&h=libreoffice-6-0 tdf#115438 Fix freeze when pasting unformatted text It will be available in 6.0.7. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 119476 has been marked as a duplicate of this bug. ***
*** Bug 119704 has been marked as a duplicate of this bug. ***
*** Bug 115636 has been marked as a duplicate of this bug. ***