Description: When several windows of an active app and even of inactive apps other than LO are visible (via clicking on their Dock icons or Command+Tabbing), and a LO window is visible behind them, hovering over toolbar items or other tooltip-triggering interface elements will bring up the LO window atop all other windows except the active, topmost one. This breaks the multi-window paradigm of macOS. Steps to Reproduce: 1. Open LO (either the splash screen or a document window will work); 2. Open several windows from other apps, without obscuring LO 3. Hover above elements that trigger tooltips Actual Results: The LO window showed a tooltip but also moved on the Z-axis and obscured all windows except the topmost, active one. Expected Results: LO should either just show a tooltip, or not react at all when not being the active application. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.4.2.3 / LibreOffice Community Build ID: 382eef1f22670f7f4118c8c2dd222ec7ad009daf CPU threads: 10; OS: Mac OS X 13.0.1; UI render: Skia/Raster; VCL: osx Locale: pt-PT (pt_PT.UTF-8); UI: pt-PT Calc: threaded
Can't reproduce in: Version: 7.4.2.3 / LibreOffice Community Build ID: 382eef1f22670f7f4118c8c2dd222ec7ad009daf CPU threads: 2; OS: Mac OS X 12.6.1; UI render: default; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Did that start after updating to Ventura?
Possibly, yes. I cannot verify it right now, but I do have another MacBook running Monterey, which I may upgrade to 7.4.2.3, and I'll get back at you once I test it there. I can also try and reproduce this on my main MacBook Pro and on a 5K iMac, both running Ventura.
Small update: I could not reproduce the issue under Monterey 12.4 (x86-64). I will try updating this MacBook to the last version of Monterey and reproducing the bug again.
[Automated Action] NeedInfo-To-Unconfirmed
I can confirm this with macOS 13.0.1 and LO 7.3.7.2.
This behaviour may be related. macOS 13.0.1, LO 7.3.7.2, both Intel and Arm. 1) Create two new LO Writer documents 2) Tile them so at least part of a toolbar is visible for the back window 3) Hover over a toolbar icon in the back window The back window comes to the front, but the window widgets (close, hide, zoom) are not active and there is no editing cursor 4) Type something Nothing appears in the front window. 5) Switch to the back window (don't use Cmd + ` or you'll crash) The stuff you typed is in the now-front window.
Thanks Bill for confirming, and João for testing some more.
*** Bug 152953 has been marked as a duplicate of this bug. ***
This behaviour still persists in LOo 7.4.4.2 (85569322deea74ec9134968a29af2df5663baa21) on macOS 13.1 (22C65).
*** Bug 153821 has been marked as a duplicate of this bug. ***
*** Bug 154046 has been marked as a duplicate of this bug. ***
This behaviour still persists in LOo 7.5.1.2 (fcbaee479e84c6cd81291587d2ee68cba099e129) on macOS 13.3.1 (22D68).
Sorry, I made a typo. The macOS version is obviously 13.2.1.
I can see the behaviour described in Comment #6, but not in the initial comment.
(In reply to Tor Lillqvist from comment #14) > I can see the behaviour described in Comment #6, but not in the initial > comment. Both behaviours are likely related (LibreOffice is apparently aggressive about its tooltips, and they are part of the window they're associated with), but I can see both happening. Honestly, the best course of action at this moment would be to just add a check to whether a window is active or not and just disable tooltips on those altogether. How likely are you to need them in inactive windows, at this point? Also, can they be disabled? Yes, they can be useful, but honestly, I'd just rather deal with the hassle of turning them on and off again if I need them (a toolbar button would be great for that, I'll check whether that's an option, too) than bumping into this annoying bug all the time. I have a thesis to write, and that includes having quite a few windows open and intermixed with LOo Writer across two displays, so as you may guess, it rears its ugly head very often. And I'm following this thread, which means that if and when this bug is fixed and the thread itself is closed I will get a notification, am I right? By then, I can turn tooltips back on permanently again.
(In reply to João Gomes from comment #15) > (In reply to Tor Lillqvist from comment #14) > > I can see the behaviour described in Comment #6, but not in the initial > > comment. > > Both behaviours are likely related (LibreOffice is apparently aggressive > about its tooltips, and they are part of the window they're associated > with), but I can see both happening. > > Honestly, the best course of action at this moment would be to just add a > check to whether a window is active or not and just disable tooltips on > those altogether. How likely are you to need them in inactive windows, at > this point? Also, can they be disabled? Yes, they can be useful, but > honestly, I'd just rather deal with the hassle of turning them on and off > again if I need them (a toolbar button would be great for that, I'll check > whether that's an option, too) than bumping into this annoying bug all the > time. > > I have a thesis to write, and that includes having quite a few windows open > and intermixed with LOo Writer across two displays, so as you may guess, it > rears its ugly head very often. > > And I'm following this thread, which means that if and when this bug is > fixed and the thread itself is closed I will get a notification, am I right? > By then, I can turn tooltips back on permanently again. It seems there isn't an exposed regular setting (and, sadly, a toolbar item for that), but for anyone wondering how to do it in, this forum post shows you how to do it on Expert Configuration: https://ask.libreoffice.org/t/how-to-turn-on-tooltips/35411 Success! Bug averted indefinitely. But please do fix this, as we should not be expected to gimp LOo in order to be able to use it or to consider any of this normal. It makes the app feel glitchy and unpolished, because that's precisely what it is, sorry.
Also… it's been more than four months and we've got massive updates in the meantime, and yet… a bug that should be fixable with a couple of lines of code is still lingering. I reckon it shouldn't be too complicated, but full disclaimer, I'm not a programmer; still, I'm guessing that checking whether an application status is active or inactive, and setting this boolean value accordingly on a per-window basis (or, indeed for the entire application), shouldn't be that big of a deal). Also, even if the underlying bug is fixed and LOo doesn't take over the entire z-axis stack except for the topmost, active window from a different application, said boolean value *should* be set as false. I've just checked how tooltips behave in Microsoft Word, Adobe InDesign and even the Finder itself, and indeed tooltips are outright disabled in inactive apps. You should check Apple's Mac HIG documentation, because I'm almost 100% sure there's something in there about tooltips, but in the absence of it, best practices should take over. Accordingly, adding that fix *right now* would at least mitigate the seriousness of this bug and, indeed, guarantee it would be limited to the behaviour described in Comment #6, as Lillqvist said.
Separately confirmed on Version: 7.5.1.2 (AARCH64) / LibreOffice Community Build ID: fcbaee479e84c6cd81291587d2ee68cba099e129 CPU threads: 8; OS: Mac OS X 13.2.1; UI render: Skia/Raster; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Calc: threaded
(In reply to Alex Thurgood from comment #18) > Separately confirmed on > > Version: 7.5.1.2 (AARCH64) / LibreOffice Community > Build ID: fcbaee479e84c6cd81291587d2ee68cba099e129 > CPU threads: 8; OS: Mac OS X 13.2.1; UI render: Skia/Raster; VCL: osx > Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR > Calc: threaded I use macOS Monterey day-to-day and I could not reproduce this. But on Ventura it is easy to reproduce. Clearly Apple changed something as I don't ever remember inactive applications getting mouse move events. Only mouse drag events were sent in such cases. But sure enough, starting with Ventura, macOS sends mouse move events to LibreOffice. Of course, all of Apple's application work fine with this (surprise, surprise) but these mouse move events confuse the LibreOffice code since every previous release of macOS didn't do this. How to fix this bug? I don't know yet. But it seems to me there might be two separate issues that need to be solved: 1. Tooltips are displayed when the application is unfocused 2. LibreOffice gets pushed up a level in the Z window order I am hoping the second case is triggered by the first case. I'll have to see as I think the tooltip handling code is a layer or two above the native event handler code that I am familiar with.
(In reply to Patrick Luby from comment #19) > (In reply to Alex Thurgood from comment #18) > > Separately confirmed on > > > > Version: 7.5.1.2 (AARCH64) / LibreOffice Community > > Build ID: fcbaee479e84c6cd81291587d2ee68cba099e129 > > CPU threads: 8; OS: Mac OS X 13.2.1; UI render: Skia/Raster; VCL: osx > > Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR > > Calc: threaded > > 1. Tooltips are displayed when the application is unfocused > 2. LibreOffice gets pushed up a level in the Z window order Don’t forget that this also happens with inactive LibreOffice windows even when LibreOffice is the active application. Also, and I don’t know if this is related to this bug, LibreOffice breaks macOS windowing conventions in that when you attempt to screenshot a modal window/dialog by pressing Command+Shift+4 followed by the space bar, the entire ensemble (document window + modal window) is captured. Something’s definitely off about the way LibreOffice manages its elements, because a modal window and a document window could very well be linked and move together, but are clearly at different positions on the Z axis and shouldn’t be flattened into the same plane; this also means you can’t move those modal windows to a secondary screen while using Mission Control with different spaces, as they will just become invisible/unreachable and must be closed by pressing the Escape key. I never thought I’d still be saying this in 2023, but LibreOffice still feels too much like a Linux or Windows application grafted onto the Mac, with zero respect for the HIG. Heck, even with SVG toolbar icons, it still fails to render then at Retina resolutions (I am obviously filing all these as separate bug reports, worry not).
(In reply to João Gomes from comment #20) > (I am obviously filing all these as separate bug reports, worry not). Already exist as bug 31915 bug 61768 and bug 130678
(In reply to eisa01 from comment #21) > (In reply to João Gomes from comment #20) > > (I am obviously filing all these as separate bug reports, worry not). > > Already exist as bug 31915 bug 61768 and bug 130678 Oh, okay, thank you for pointing it out. I'll be sure to check them out and see if there's anything of value I can add.
(In reply to João Gomes from comment #22) > (In reply to eisa01 from comment #21) > > (In reply to João Gomes from comment #20) > > > (I am obviously filing all these as separate bug reports, worry not). > > > > Already exist as bug 31915 bug 61768 and bug 130678 > > Oh, okay, thank you for pointing it out. > > I'll be sure to check them out and see if there's anything of value I can > add. Indeed there is. Neither those first two bug reports (or maybe the second one, I don't think I fully understand the scope of the first one), nor the subsequent comments address the ensuing issue with external displays. That alone doesn't warrant an entry of its own, as the underlying behaviour that causes it is the same, but is indeed yet another “buggy” and “undesirable” expression/effect thereof.
*** Bug 153776 has been marked as a duplicate of this bug. ***
*** Bug 154885 has been marked as a duplicate of this bug. ***
> I never thought I’d still be saying this in 2023, but LibreOffice still > feels too much like a Linux or Windows application grafted onto the Mac, > with zero respect for the HIG. I can only agree. My belief is that for LibreOffice to feel truly native on macOS the whole topmost application layer needs to be re-written for the Mac. Avoid all the horrors in the current cross-platform top-level code. I mean things like SVMain(), ImplSVMain(), etc. Write a "new" app from the top the "proper" way, using NSDocument etc, and then attach that to existing LO code suitably. But I am not volunteering.
*** Bug 154974 has been marked as a duplicate of this bug. ***
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/3bc7cc14706f47d740dfc5715970054922ca470c tdf#152173 Don't display tooltip windows when application is inactive It will be available in 7.6.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.
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/b6c0738f2a1906c2b5a967793e9b065a1b43d75e tdf#152173 Don't display tooltip windows when application is inactive It will be available in 7.5.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.
*** Bug 155220 has been marked as a duplicate of this bug. ***
Verified. When LO is not in focus and tooltip elements are hoovered with the mouse, they highlight but the tooltip no longer shows as expected when the LO window is not in focus. Thanks Patrick. Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 002ae41bb6088002ba3ed0188ac822fb823a23f9 CPU threads: 8; OS: Mac OS X 13.3.1; UI render: Skia/Metal; VCL: osx Locale: en-US (en_DE.UTF-8); UI: en-US Calc: threaded
(In reply to steve from comment #31) > Verified. > > When LO is not in focus Does this fix the issue from comment 6 where LO is the front application, there are multiple windows open and hovering over a toolbar icon brings a back LO window to the front?
(In reply to Bill from comment #32) > Does this fix the issue from comment 6 where LO is the front application, > there are multiple windows open and hovering over a toolbar icon brings a > back LO window to the front? I don't think so. The next time that I am running Ventura (most of my time is spent running Monterey), I'll see if I can add some extra code to my fix for when the application is active but the tooltip's parent window is not the key window. Are there other cases (tooltips or otherwise) that cause a non-key (i.e. unfocussed) window to move forward that I have missed?
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/bf2cf747303d1485fac44e0d7250541094fe9724 tdf#152173 Don't display tooltip windows when mousing over non-key windows It will be available in 7.6.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.
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/b69db38a38b09e158e8d46d8b717db85860ca874 tdf#152173 Don't display tooltip windows when mousing over non-key windows It will be available in 7.5.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.
I can confirm is resolved on 7.5.4
*** Bug 156359 has been marked as a duplicate of this bug. ***
*** Bug 155703 has been marked as a duplicate of this bug. ***
*** Bug 156425 has been marked as a duplicate of this bug. ***
stragu, the recent upgrade (I do use brew for app management) as you suggested has indeed fixed this issue. Thanks for the response!
Making a minor after-the-fact adjustment to "Version earliest affected" field: changing 7.3.7.2 to 7.0.0.3 I was running 7.1.0.3 when I first noticed the issue. It may have appeared even earlier. LO 7.6.5.2 on OSX 13.6.3 Ventura is OK/fixed.