Description: UI: comment box oversized on file open until click in document (triggering a resize) Steps to Reproduce: 1. Open attachment 175224 [details] Actual Results: Full page comment Expected Results: Matching text size comment Reproducible: Always User Profile Reset: No Additional Info: Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: d5e55d204b71710eb5eb5d2c683dd6698626df3c 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
Created attachment 175232 [details] Bibisect log Comment box covering the full page started with author Caolán McNamara <caolanm@redhat.com> 2020-12-04 16:30:31 +0000 committer Caolán McNamara <caolanm@redhat.com> 2021-02-06 12:16:04 +0100 commit 69c546e1e7a697217f273baa7c1729ff823efd76 (patch) tree 4533c38b84d1cd57f86094ac816f0eb7c526ade1 parent 2c61782812b1b8b382dd48a04a712da9eaeb4685 (diff) weld annotation window note the labels in sw/uiconfig/swriter/ui/annotation.ui are deliberately yaligned to 0 to retain the preexisting SwAnnotationWin::PaintTile hack which depends on this for bin/run gtktiledviewer --enable-tiled-annotations to not show clipped author/date/etc labels https://cgit.freedesktop.org/libreoffice/core/commit/?id=69c546e1e7a697217f273baa7c1729ff823efd76 But.. before this the comment box being the small (and expanding size after movement).. so broken too..
Created attachment 175238 [details] Bibisect log Bisected the undersized comment window to: author Miklos Vajna <vmiklos@collabora.com> 2019-09-16 21:15:28 +0200 committer Miklos Vajna <vmiklos@collabora.com> 2019-09-17 08:57:15 +0200 commit c56bf1479cc71d1a2b0639f6383e90c1f7e3655b (patch) tree 3db679971be5be40d2f737202de6b8106dc1d53c parent 813cca94cd3a08d98c09fc7c34afddd02dc912ce (diff) tdf#105330 sw: fix lost cursor on undoing nested table insert This is a regression from commit e4509eea8fc7c07ddff48edf0d4c015c2663d896 (n#751313 SwCallLink: avoid redrawing complete rows without nested tables, 2012-04-20), though manual testing shows that the underlying problem has been addressed in the meantime, so this can be reverted. Over time, some poor tests started to depend on the new behavior so adapt them as necessary: 1) Change back test added in commit 075fc0c0a34875adf2833e5933b4982b9443a373 (testcase for fdo#38414, 2014-03-18) to its original form, that was changed to an export test in commit 086550313260d9fa45b91dc705b21bb9b51ce0b8 (move round-tripables to ooxmlexport, 2016-10-07), as the export of that document still results in data loss of cell content, just happened to pass so far. 2) Explicitly calculate content of text frames in two more tests, which just hoped that by the time they assert, the layout is ready already (but now that the missing notification is restored, it happens that the first pass of the layout doesn't create them; only a later pass, invoked by Idle, which doesn't run during cppunit tests). https://cgit.freedesktop.org/libreoffice/core/commit/?id=c56bf1479cc71d1a2b0639f6383e90c1f7e3655b
Can't confirm with Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 56883788d0090383dad58552f5a11044ffe64a44 CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL
(In reply to Dieter from comment #3) > Can't confirm with > > Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community > Build ID: 56883788d0090383dad58552f5a11044ffe64a44 > CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: > win > Locale: de-DE (de_DE); UI: en-GB > Calc: CL Odd, present for me: Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 93115d2c54d645bcf2f80fde325e3ede39dee4d5 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
(In reply to Telesto from comment #4) > Odd, present for me: Telesto, could you add a screenshot?
Created attachment 175653 [details] Screenshot on file open
Created attachment 175752 [details] Screenshot My result.
(In reply to Dieter from comment #7) > Created attachment 175752 [details] > Screenshot > > My result. The possible difference You opened it Read-only (and changed to edit mode). I in normal mode.
(In reply to Telesto from comment #8) > You opened it Read-only (and changed to edit mode). I in normal mode. Since some versions, it's not possible for me to open in normal mode. When opening a docment I always revieve a "Document is read-only" dialog. Are there any settings, I don't know?
(In reply to Dieter from comment #9) > (In reply to Telesto from comment #8) > > You opened it Read-only (and changed to edit mode). I in normal mode. > > Since some versions, it's not possible for me to open in normal mode. When > opening a docment I always revieve a "Document is read-only" dialog. Are > there any settings, I don't know? Hmm, it might be browser related? I save file first, and open it from the stored location. But directly opening doesn't cause trouble here either hwere (Chromium based browser) And you can check if the file itself gets the 'read-only flag. Right click the file -> Properties tab. There is a 'read-only' option. And you could do a profile reset of LibO of course.
Very strange. Tested with Version: 7.2.2.2 (x64) / LibreOffice Community Build ID: 02b2acce88a210515b4a5bb2e46cbfb63fe97d56 CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: CL Results: When I open attachment 175224 [details] directly, it works with Firefox but produces the bug with Chrome. Bug alos happen, when I save the document first and then open it directly from desktop or in writer. =>NEW
Adding CC: to Caolán McNamara author Caolán McNamara <caolanm@redhat.com> 2020-12-04 16:30:31 +0000 committer Caolán McNamara <caolanm@redhat.com> 2021-02-06 12:16:04 +0100 commit 69c546e1e7a697217f273baa7c1729ff823efd76 (patch) tree 4533c38b84d1cd57f86094ac816f0eb7c526ade1 parent 2c61782812b1b8b382dd48a04a712da9eaeb4685 (diff) weld annotation window note the labels in sw/uiconfig/swriter/ui/annotation.ui are deliberately yaligned to 0 to retain the preexisting SwAnnotationWin::PaintTile hack which depends on this for bin/run gtktiledviewer --enable-tiled-annotations to not show clipped author/date/etc labels https://cgit.freedesktop.org/libreoffice/core/commit/?id=69c546e1e7a697217f273baa7c1729ff823efd76 I'm cherry-picking a developer here: the commit above is involved, but the problem runs deeper.
The "too tall" issue is a duplicate of tdf#143443 ; at least the fix there restores the 7.1 behavior back to what's noted in comment #1
I think it might be helpful to set the papersize from the start to the "sidebarwidth" that it ends up as eventually, that way there wouldn't be those weird in-between heights that have been used in this case.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c0597c3126d6be683bd2085d1213b8b47f431558 Resolves: tdf#144686 set the initial "papersize" to the sidebarwidth It will be available in 7.3.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.
it seems more sensible to always calculate the text layout of these using the sidebar width rather than start with an unlimited width and that makes this case apparently work ok, so call that fixed in trunk and there's a backport to 7-2 in gerrit
*** Bug 145380 has been marked as a duplicate of this bug. ***
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-7-2": https://git.libreoffice.org/core/commit/cff943453a8d42b64b8019b43f6cdc934d5d5f44 Resolves: tdf#144686 set the initial "papersize" to the sidebarwidth It will be available in 7.2.3. 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.
VERIFIED with Version: 7.3.0.0.alpha1+ (x64) / LibreOffice Community Build ID: 742b8befecbcfc0cfab87cfcd87c83b7d8ef32ab CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL Caolán, thank you for fixing it!