Created attachment 158250 [details] Document with three consecutive sections. Open the attached document. It contains the explaining text and three consecutive sections with minimal content, so it's easier to test. What can be observed is the following. As far as I can say, this doesn't depend on zooming. The only stable behavior is: remove the 2nd section and the top border of the 3rd section moves by a pixel, or sometimes vanishes completely. Sometimes you have a double / two pixel border on load. This is sometimes even triggered by a reload. Change the 2nd section in any of the following ways: • add a line • remove a line • remove the whole 2nd section via Format > Sections… „Bereich 2“ Results can be one of the following: • 3rd section top border moves by a pixel (always happens when the 2nd section is removed – best observed via undo + redo) • 3rd section top border isn‘t painted at all, until refresh like scrolling out of view (seldom) • 1st section bottom border / 2nd section top border result in two lines (seldom) Eventually some merging of borders is happening. From the layout definition, they don't take any space, which IMHO makes sense. These frames just act as a visible hint and don't affect the layout. So maybe all sections should simply draw their frames, so for consecutive sections, these are always doubled? But probably we still need some extra handling, if the device pixels match to the same line. The worst problem, and the origin of this report, is the missing top border of the 3rd section on delete, which should never happen. That looks like a refresh problem, but it isn't. The border is simply not painted, because Writer doesn't realize the upper border needs repaint. In the debugger I can see, that no painting for this line happens at all, but happens in the correct case in SwSubsRects::PaintSubsidiary. If the user triggers a new paint of the section (scroll the section out of view, minimize+restore, ...), the border becomes visible. I think, this is basically all the same bug.
(In reply to Jan-Marek Glogowski from comment #0) > [...] > Results can be one of the following: > • 3rd section top border moves by a pixel > (always happens when the 2nd section is removed – best observed via undo + > redo) This behaviour reliably reproducible for me with Version: 7.0.0.0.alpha0+ Build ID: e5f81b90629c5f3bd733f862d17a57c251acc291 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3; Locale: en-GB (en_GB.UTF-8); UI-Language: en-US Calc: threaded
Serge Krot committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/8666dfecbaac69b9dc9a9c23a05654d847608907 tdf#131004 fix unstable paint of writer consecutive section frames 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.
Serge Krot committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/27b775647e8fd557d5581b6416f3f35f5ae02b4d tdf#131004 fix unstable paint of writer consecutive section frames It will be available in 6.4.4. 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.