1. Start new default text document 2. Check that text boundaries and non-printing characters are shown > there is the text boundary and a paragraph mark. 3. Type text and text over more lines... > see that text boundaries disappear 4. Type Enter > most text boundaries are gone 5. Ctrl+F10 off and on > only some fragments of the boundaries are shown Saw this ~a week ago; hoped it would disappear by magic ;) Version: 5.3.0.0.alpha0+ Build ID: 139d3b3e8b157c1f365f888126269f0902acbaa2 CPU Threads: 4; OS Version: Linux 4.4; UI Render: default; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2016-08-26_00:01:39 Locale: nl-NL (nl_NL.UTF-8); Calc: group
Hi Cor, with win10x64 and Version: 5.3.0.0.alpha0+ Build ID: ea9a90d83d92076d41abfd31a1fd3a5d84b6ba92 CPU Threads: 4; OS Version: Windows 6.19; UI Render: GL; TinderBox: Win-x86@39, Branch:master, Time: 2016-08-26_06:19:43 Locale: es-ES (es_ES); Calc: CL I can see it, enabled or not OpenGL.
Do not see any glitches on Windows builds on Windows 8.1 Ent 64-bit en-US with nVidia OpenGL drivers. No issues typing in text, and clean on/off toggle <Ctrl>+F10 of borders & hidden mark-up. Version: 5.3.0.0.alpha0+ Build ID: 1f46cbf32a668e80f520d27093f56d6b61550852 CPU Threads: 8; OS Version: Windows 6.29; UI Render: GL; TinderBox: Win-x86@42, Branch:master, Time: 2016-08-30_00:41:48 Locale: en-US (en_US); Calc: CL
Created attachment 127577 [details] Screenshot of the problem Repro. Arch Linux 64-bit, KDE Plasma 5 Version: 5.3.0.0.alpha0+ Build ID: cd72269a6a2c85ae9dd4552aa4808ef4fd1f6c0e CPU Threads: 8; OS Version: Linux 4.7; UI Render: default; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on September 21st 2016
Are there any particular reproduction steps? Couldn't reproduce it with the new bibisect repo. Version: 5.3.0.0.alpha0+ Build ID: e5981249db34db2367bae2a2f3e7e8d9f8bd09a0 CPU Threads: 4; OS Version: Linux 4.4; UI Render: default; Locale: en-US (en_US.UTF-8); Calc: group
(In reply to Aron Budea from comment #4) > Are there any particular reproduction steps? Couldn't reproduce it with the > new bibisect repo. For me the steps in the original report still work 'fine' ;)
I can't reproduce it in Version: 5.3.0.0.alpha0+ Build ID: 0d3ba1d4b507b555b086c687fcd202d69a9a2ffa CPU Threads: 4; OS Version: Linux 4.2; UI Render: default; Locale: ca-ES (ca_ES.UTF-8); Calc: group
*** Bug 103766 has been marked as a duplicate of this bug. ***
starting to bibisect this in bibisect-linux-64-5.3 Version: 5.3.0.0.alpha1+ Build ID: 8dc495c93239739629683bb29e4110f5c57c94f0 CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk3; Locale: nl-NL (nl_NL.UTF-8); Calc: group I cannot reproduce the bug there. NB this repo is up to date 2016-10-23 13:31:40 (GMT) However, running a fresh daily (Version: 5.3.0.0.alpha1+ Build ID: 0af30952982767543cddd0b1ce643cb8d5c253a2 CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk2; Layout Engine: new; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2016-11-11_23:43:27 Locale: nl-NL (nl_NL.UTF-8); Calc: group) the bug is still present. So there is something different in de bibisect repo compared to daily build? GTK stuff, or ... ? Any hint :) ? thanks!
the only difference I see is that the bibisect repo uses GTK3 and your daily build GTk2. Can you reproduce it if you run the bibisect repo as SAL_USE_VCLPLUGIN=gtk instdir/program/swriter
@armin: can you please have a look? $ git bisect bad ca41d10ea9bb940168337d096663223007e14407 is the first bad commit commit ca41d10ea9bb940168337d096663223007e14407 Author: Jenkins Build User <tdf@pollux.tdf> Date: Wed Sep 28 08:53:21 2016 +0200 source cb382034b061b4acd4f0fd490f42af34517a7b8d source cb382034b061b4acd4f0fd490f42af34517a7b8d :040000 040000 02c338195ea1b9c3da49d2cf38467043f134f2d0 faefda82663cbc1dd6ecd39058f95942464b1242 M instdir $ git bisect log # bad: [845539f0cf09355a7baa6d1cfbf6ad478a983da5] source 8dc495c93239739629683bb29e4110f5c57c94f0 # good: [33e60eae04c889baf52713a73dc9944015408914] source 5b168b3fa568e48e795234dc5fa454bf24c9805e git bisect start 'latest' 'oldest' # bad: [9e0af0bfb61955f2a7bcae3a25a403cfc01919f4] source e8365711e817876ee45b282fc16977b55f4dbca8 git bisect bad 9e0af0bfb61955f2a7bcae3a25a403cfc01919f4 # good: [da61bbd66b4fdfa9fa120dac29ccdc3078afd846] source 09353c627822d61fbffd6038224d0da72f768710 git bisect good da61bbd66b4fdfa9fa120dac29ccdc3078afd846 # bad: [fd6107d5e5eb363779570d821939c5e1d0539bed] source 31623bb04a86cc848beec359bd7567833aad5fd3 git bisect bad fd6107d5e5eb363779570d821939c5e1d0539bed # bad: [2e1a04446c6c60bea243113a08a3541ad9f550be] source efbe959732687d7a96041a3f7b90e817abbd8145 git bisect bad 2e1a04446c6c60bea243113a08a3541ad9f550be # good: [8ed56dc81f82482c1d242c0010f7f3966b16a0bc] source f904bd567facfe29c81f99100f924e3cd1385312 git bisect good 8ed56dc81f82482c1d242c0010f7f3966b16a0bc # good: [8954becd40e0675ecebb35729b86ca7b8492e2d3] source 049eed046a27cb9d48e89d9e228cd3a4f91ec548 git bisect good 8954becd40e0675ecebb35729b86ca7b8492e2d3 # good: [f87b5ce64da2ef034b7ba5a7ce0812a02c29a019] source 3ada0545adc7533c02b37cb55f0cab09dcdac96b git bisect good f87b5ce64da2ef034b7ba5a7ce0812a02c29a019 # good: [e076e507d65a9ac4e63569e22b7384a0eb67c5a0] source 8550366138d576123b9e66a1a7915a04026d79cd git bisect good e076e507d65a9ac4e63569e22b7384a0eb67c5a0 # bad: [0dbd1ff8546a11c4897baa9200bba830fff85d6b] source 54f2a4184d1296814e64cfeab1d06ae90d002357 git bisect bad 0dbd1ff8546a11c4897baa9200bba830fff85d6b # bad: [73bd00b05d97abff227b685c20e305ae829f0f80] source c1f476d91805e6a9573bba3ea8f5f980e0ea7b54 git bisect bad 73bd00b05d97abff227b685c20e305ae829f0f80 # bad: [155c1848ff10ebc2d4002ffa249d66ea7a6a99fc] source 9f0766917a4fb1bc8fe1786c3b46132dd63c1c66 git bisect bad 155c1848ff10ebc2d4002ffa249d66ea7a6a99fc # bad: [f7cfd4b1ee178edfe0447293f9fd3e5476bfbcf9] source 30fdc46969f3c90c47cddf18d0dde640c8ea280e git bisect bad f7cfd4b1ee178edfe0447293f9fd3e5476bfbcf9 # bad: [ca41d10ea9bb940168337d096663223007e14407] source cb382034b061b4acd4f0fd490f42af34517a7b8d git bisect bad ca41d10ea9bb940168337d096663223007e14407 # first bad commit: [ca41d10ea9bb940168337d096663223007e14407] source cb382034b061b4acd4f0fd490f42af34517a7b8d
Adding Cc: to Armin Le Grand
*** Bug 105750 has been marked as a duplicate of this bug. ***
(In reply to Buovjaga from comment #12) > *** Bug 105750 has been marked as a duplicate of this bug. *** This duplicate says: Bug only exists when Hardware Acceleration is activated. Rendering with OpenGL, then everything is fine. (on Linux)
(In reply to Buovjaga from comment #13) > This duplicate says: > Bug only exists when Hardware Acceleration is activated. For me that makes no difference. Version: 5.4.0.0.alpha0+ Build ID: d3293c7173210e0246d0dc29377f687f41588da2 CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-02-11_00:45:56 Locale: nl-NL (nl_NL.UTF-8); Calc: group
*** Bug 105791 has been marked as a duplicate of this bug. ***
On Linux with GTK2, in LO 5.4.1.2 the bug is still there. It can be quickly reproduced by entering the following text in an empty document: - example then pressing the Enter key makes the text boundaries completely disappear. The bug does not appear with GTK3, but there are other issues that makes me prefer GTK2.
*** Bug 107664 has been marked as a duplicate of this bug. ***
This issue is also present with LibreOffice 5.4.3.2 in an KDE/Plasma environment, no matter if openGl and hardware acceleration are on or off. I tested it with both Nvidia and Intel drivers.
The issue does not appear with GTK3. However, scrolling documents with a lot of images (graphics, equations) is much slower with GTK3. This why I don't use GTK3 (and there are also some glitches with the UI in GTK3). So, please fix this bug...
*** Bug 116834 has been marked as a duplicate of this bug. ***
*** Bug 117950 has been marked as a duplicate of this bug. ***
@Caolán, I thought you could be interested in this issue...
This is a one liner bug
https://gerrit.libreoffice.org/#/c/55177/
(In reply to Caolán McNamara from comment #24) > https://gerrit.libreoffice.org/#/c/55177/ I verified I could still repro with master and then applied this patch and the problem did not appear. Arch Linux 64-bit Version: 6.2.0.0.alpha0+ Build ID: bb98700bab4e72551b72335bd443e1b3d4aa4916 CPU threads: 8; OS: Linux 4.16; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group threaded Built on June 1st 2018
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-6-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=833a76113d588b0e7ce375ccdeca0bde516a2647&h=libreoffice-6-1 Resolves: tdf#101798 ResetClipRegion needs to affect cairo drawing too It will be available in 6.1.0.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.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=dde1586c5eebe86deeb1126cde539b3932e2d5a1 Resolves: tdf#101798 ResetClipRegion needs to affect cairo drawing too 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.
Verified in Version: 6.1.0.0.beta1+ Build ID: b57819201ff89bbde14b4df8c02a0eb4bea2c2bb CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk2; Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded @Caolán, Thank you very much for fixing this!!
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-6-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=77230756187d8642f08e6b4bb937d279f3483533&h=libreoffice-6-0 Resolves: tdf#101798 ResetClipRegion needs to affect cairo drawing too It will be available in 6.0.6. 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.