Bug 164337 - Full screen floating toolbar moves offscreen after a few cycles in full screen mode
Summary: Full screen floating toolbar moves offscreen after a few cycles in full scree...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
24.2.5.2 release
Hardware: ARM macOS (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:25.8.0
Keywords:
Depends on:
Blocks:
 
Reported: 2024-12-15 21:20 UTC by Patrick (volunteer)
Modified: 2025-05-07 11:42 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
position "Pos" values for fullscreenbar and standardbar objects on sequence of opening then toggling FullScreen mode (38.23 KB, text/plain)
2025-05-04 13:26 UTC, V Stuart Foote
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Patrick (volunteer) 2024-12-15 21:20:11 UTC
Description:
Open a new Writer or Calc document and select the View > Full Screen menu. The document will go into LibreOffice's full screen mode where, on macOS, the menubar and Dock are both hidden. To escape out of full screen mode, there should be a floating "Full Screen" toolbar should appear over the top left corner of the document window.

Steps to Reproduce:
The bug is that after escaping out of full screen mode, the next time I reenter full screen mode the floating "Full Screen" toolbar is shifted leftward and rightward by the document window's X and Y non-full screen position. After a few cycles into and out of full screen mode, floating toolbar is position offscreen.

Actual Results:
Since the menubar is not hidden but also disabled, the only way to escape out of full screen mode is by entering the Escape key.

Expected Results:
The floating full screen toolbar should not be shifted.


Reproducible: Always


User Profile Reset: Yes

Additional Info:
Can anyone reproduce this on Windows or Linux?

My first is that this is a macOS-only bug but I want to confirm whether I should fix this in macOS or cross-platform code.
Comment 1 Patrick (volunteer) 2024-12-15 21:49:14 UTC
So here is what I have found so far: SystemWindow::UpdatePositionData() gets called for the floating toolbar immediately after escaping full screen mode. When this is called, the document window has already been moved and resized to its non-full screen size.

I can stop the bug from occurring by commenting out Window::ImplCallMove() using the debug patch below. It appears that Window::ImplCallMove() expects all child windows to automatically be pinned to their parent window so when the parent window moves, all of its children move too.

Not if this is a problem on Windows or Linux, but on macOS I found that in Window::ImplCallMove() although the parent window had already been moved and resized but the floating toolbar has not.

My next step depends on whether or not this bug occurs on Windows or Linux:


diff --git a/vcl/source/window/floatwin.cxx b/vcl/source/window/floatwin.cxx
index 196f2126cf5b..9ba90632f627 100644
--- a/vcl/source/window/floatwin.cxx
+++ b/vcl/source/window/floatwin.cxx
@@ -960,7 +960,7 @@ bool SystemWindow::UpdatePositionData()
     if (pWin)
     {
         // Simulate Move, so the relative position of the floating window will be recalculated
-        pWin->ImplCallMove();
+        // pWin->ImplCallMove();
         return true;
     }
Comment 2 Patrick (volunteer) 2024-12-30 16:24:36 UTC
(In reply to Patrick (volunteer) from comment #1)
> My next step depends on whether or not this bug occurs on Windows or Linux:

So can anyone confirm if this bug occur on Windows or Linux? Or is this a macOS-only bug?
Comment 3 Saburo 2025-01-18 07:33:28 UTC
On Windows, the toolbar would move to the top left corner, but it never went off the screen.
---
Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: c9ae567c791bcffdc3fff9e3fb11b46275a13d2b
CPU threads: 12; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster; VCL: win
Locale: ja-JP (ja_JP); UI: ja-JP
Calc: CL threaded

On ubuntu(virtualbox) the toolbar disappeared from the second time, I think this is another bug.
---
Version: 24.8.4.2 (X86_64) / LibreOffice Community
Build ID: bb3cfa12c7b1bf994ecc5649a80400d06cd71002
CPU threads: 4; OS: Linux 6.8; UI render: default; VCL: gtk3
Locale: ja-JP (ja_JP.UTF-8); UI: ja-JP
Calc: threaded

On kubuntu(virtualbox) the toolbar moved downwards but never disappeared off the screen.
---
Version: 24.8.4.2 (X86_64) / LibreOffice Community
Build ID: bb3cfa12c7b1bf994ecc5649a80400d06cd71002
CPU threads: 4; OS: Linux 6.5; UI render: default; VCL: kf5 (cairo+xcb)
Locale: ja-JP (ja_JP.UTF-8); UI: ja-JP
Calc: threaded

On xubuntu(Virtualbox) the toolbar moved downwards but never disappeared off the screen.
---
Version: 24.8.4.2 (X86_64) / LibreOffice Community
Build ID: bb3cfa12c7b1bf994ecc5649a80400d06cd71002
CPU threads: 2; OS: Linux 6.5; UI render: default; VCL: gtk3
Locale: ja-JP (ja_JP.UTF-8); UI: ja-JP
Calc: threaded

On OpenSUSE(VirtualBox) the toolbar hardly moved.
---
Version: 24.8.3.2 (X86_64) / LibreOffice Community
Build ID: 480(Build:2)
CPU threads: 4; OS: Linux 6.12; UI render: default; VCL: gtk3
Locale: ja-JP (ja_JP.UTF-8); UI: ja-JP
Calc: threaded
Comment 4 V Stuart Foote 2025-05-04 13:26:51 UTC
Created attachment 200645 [details]
position "Pos" values for fullscreenbar and standardbar objects on sequence of opening then toggling FullScreen mode

Confirmed, affecting 25.2.3 and recent master against 25.8.0 on Win11. Single 4K monitor. FullscreenToolbox tb object ends up in the top left corner with large negative positions recorded to user profile.

Sequence of .XCU profile stanzas for 'fullscreenbar' and 'standardbar' tb  as in attached.
Comment 5 V Stuart Foote 2025-05-04 13:28:47 UTC
Confirmed on Win builds. See also bug 166452

Version: 25.2.3.2 (X86_64) / LibreOffice Community
Build ID: bbb074479178df812d175f709636b368952c2ce3
CPU threads: 28; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded

Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 3ab82581e5a5abc03c7ff06eac76a0b2fa0c9c34
CPU threads: 28; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded
Comment 6 Commit Notification 2025-05-07 11:37:39 UTC
Patrick Luby committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/3a58d8facfee21616a6a5faa5209be7a56770acf

tdf#164337 don't update position data when waiting for a system resize

It will be available in 25.8.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.
Comment 7 Patrick (volunteer) 2025-05-07 11:42:01 UTC
I have committed a patch that fixes this bug on macOS. But it needs to be tested on Windows and Linux.

My latest commit should be in tomorrow's (08 May 2025) nightly master builds:

https://dev-builds.libreoffice.org/daily/master/current.html

Note for macOS testers: the nightly master build installer does *not* overwrite any LibreOffice official versions. Instead, it will be installed as a separate application called "LibreOfficeDev" in the /Applications folder.

Because this is a "test" build, you will need to do the following steps before you launch the LibreOfficeDev application:

1. Go to the Finder and navigate to the /Applications/Utilities folder
2. Launch the "Terminal" application
3. Paste the following command in the Terminal application window and press the Return key to execute the command:

   xattr -d com.apple.quarantine /Applications/LibreOfficeDev.app