Reproduced in:

Version: 7.5.2.2 (X86_64) / LibreOffice Community
Build ID: 53bb9681a964705cf672590721dbc85eb4d0c3a2
CPU threads: 2; OS: Mac OS X 13.2.1; UI render: default; VCL: osx
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

and:

Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: fc6806c4be8585ce0d35a6b581bf8b3dbf858500
CPU threads: 2; OS: Mac OS X 13.2.1; UI render: Skia/Raster; VCL: osx
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

Can consistently see it when releasing while dragging an edge above the other LO window.
Also with Writer windows, so changing to affecting the whole of LibreOffice.

Wondering if it has something to do with the focus issue described in bug 152173.

Created attachment 187103 [details]
Sample of LibreOffice using the Activity Monitor application

I was able to reproduce this on macOS Ventura.

I was able to obtain a sample using the Activity Monitor application but I don't see much LibreOffice code in the sample. From what I can see, CPU usage skyrockets and LibreOffice is responding to a lot of "update window" events from macOS.

I am not sure where to start looking for this bug, but maybe someone else will see something in my sample that I am missing.

(In reply to Patrick Luby from comment #2)
> I am not sure where to start looking for this bug, but maybe someone else
> will see something in my sample that I am missing.

No clue. It's not MacOS Ventura specific
Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 066b23115c2a360507e306a88da572554daefab7
CPU threads: 8; OS: Mac OS X 12.6.3; UI render: Skia/Raster; VCL: osx
Locale: nl-NL (nl_NL.UTF-8); UI: en-US
Calc: threaded

Debug info shows

warn:sfx.control:75313:7973284:sfx2/source/control/dispatch.cxx:1211: Childwindow slot missing: 26190

No repro with
Version: 7.0.0.3
Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e
CPU threads: 8; OS: Mac OS X 10.16; UI render: default; VCL: osx
Locale: nl-NL (nl_NL.UTF-8); UI: en-US
Calc: threaded

No repro with 
Version: 7.4.0.3 / LibreOffice Community
Build ID: f85e47c08ddd19c015c0114a68350214f7066f5a
CPU threads: 8; OS: Mac OS X 12.6.3; UI render: default; VCL: osx
Locale: nl-NL (nl_NL.UTF-8); UI: en-US
Calc: threaded

nor with
Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 8635c9aa8c6f1078a9e220076d5a08daf30077e8
CPU threads: 8; OS: Mac OS X 12.6.3; UI render: Skia/Raster; VCL: osx
Locale: nl-NL (nl_NL.UTF-8); UI: en-US
Calc: threaded

so the problem maybe backported to the 7.5 branch, or it's working on my system for a different reason (for example user profile influence)

I can still reproduce in 7.5.4, so the fix for bug 152173 didn't help.

Version: 7.5.4.2 (X86_64) / LibreOffice Community
Build ID: 36ccfdc35048b057fd9854c757a8b67ec53977b6
CPU threads: 2; OS: Mac OS X 13.2.1; UI render: default; VCL: osx
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

I cannot reproduce this bug on macOS Sonoma 14.1.1. Is it possible that this is a bug in macOS Ventura? If anyone is running macOS Ventura 13.6.2, can you reproduce this bug?: 

Version: 7.6.2.1 (AARCH64) / LibreOffice Community
Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333
CPU threads: 8; OS: Mac OS X 14.1.1; UI render: Skia/Metal; VCL: osx
Locale: en-CA (en_CA.UTF-8); UI: en-US
Calc: threaded

The bug can be reproduced on macOS Monterey as well. (If I remember correctly it started some time with LO 7.5.)

Version: 7.6.2.1 (X86_64) / LibreOffice Community
Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333
CPU threads: 4; OS: Mac OS X 12.7.1; UI render: Skia/Raster; VCL: osx
Locale: en-GB (en_GB.UTF-8); UI: en-US
Calc: threaded

(In reply to Patrick Luby from comment #6)
> I cannot reproduce this bug on macOS Sonoma 14.1.1. Is it possible that this
> is a bug in macOS Ventura?

I can confirm that it's still present in Sonoma 14.1.1 and LibreOffice 7.6.2

I can reproduce it by starting with two spreadsheet windows open and overlapping. if you start with largish front window and reduce its size by about 25% by dragging the bottom RHS corner towards the centre. Then repeat the process. The mouse is usually okay after the first drag but starts misbehaving after the second.

I am a macOS developer but I have never looked at the LibreOffice source. That said, if this were a simple Mac application I would look at whether it was still using the old 'trackingRect' methods to control the cursor state. These are now deprecated, were always very difficult to get right, and seem to be getting very fragile on modern Macs possibly because the event queues get flooded. The recommended replacement is 'trackingAreas', which I have found to be much easier to implement and generally better behaved.

LO is not, however, a 'simple Mac application' it is complicated by its multiplatform nature so my guesswork may be worthless. I have no wish to tread on the toes of the LO Mac developers who have done an amazing job with maintaining LO for Mac users.

(In reply to libreoffice from comment #8)
> I can confirm that it's still present in Sonoma 14.1.1 and LibreOffice 7.6.2

Sorry, should have included:

Version: 7.6.2.1 (AARCH64) / LibreOffice Community
Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333
CPU threads: 8; OS: Mac OS X 14.1.1; UI render: Skia/Raster; VCL: osx
Locale: en-GB (en_GB.UTF-8); UI: en-US
Calc: threaded

(In reply to libreoffice from comment #8)
> I can reproduce it by starting with two spreadsheet windows open and
> overlapping. if you start with largish front window and reduce its size by
> about 25% by dragging the bottom RHS corner towards the centre. Then repeat
> the process. The mouse is usually okay after the first drag but starts
> misbehaving after the second.

I still cannot reproduce this on my Silicon MacBook Pro by click and dragging the bottom right hand corner on my trackpad. I was able to very briefly reproduce it (but only once) when I used three finger swiping on trackpad.

Any ideas as to what I am doing wrong?

The 'trackingRect' calls could be the cause (my quick grok of the vcl/osx code is that LibreOffice resets trackingRect to the full size of the window's content view every time the size of the window changes so maybe delaying such a reset until the window is no longer in live resize mode might also have some affect.

Once I can reproduce it on my machine, I will be better able to investigate the above possible causes.

(In reply to libreoffice from comment #8)
> I am a macOS developer but I have never looked at the LibreOffice source.
> That said, if this were a simple Mac application I would look at whether it
> was still using the old 'trackingRect' methods to control the cursor state.
> These are now deprecated, were always very difficult to get right, and seem
> to be getting very fragile on modern Macs possibly because the event queues
> get flooded. The recommended replacement is 'trackingAreas', which I have
> found to be much easier to implement and generally better behaved.

Even though I cannot reproduce this bug on macOS Sonoma, I did some debugging and LibreOffice is removing and adding tracking rectangles during live resizing. Maybe that is a potential cause of this bug?

I saw that if I switched to the newer "trackingArea" NSView selectors, I can move the tracking area updating by overriding -[NSView updateTrackingAreas]. My wild theory is that in newer versions of macOS, updating the tracking area during a live resize is unsafe.

So, just for fun I wrote the following debug patch that overrides -[NSView updateTrackingAreas]. What is interesting is that 1) it is getting called even though LibreOffice is using the older "trackingRect" selectors, and 2) it does *not* get called during live resizing. Maybe I'll just move to the newer "trackingArea" selectors and see if it has any effect:

diff --git a/vcl/inc/osx/salframeview.h b/vcl/inc/osx/salframeview.h
index f9eca27e305c..4b334fca1fb4 100644
--- a/vcl/inc/osx/salframeview.h
+++ b/vcl/inc/osx/salframeview.h
@@ -262,6 +262,8 @@ enum class SalEvent;
 -(NSArray *)accessibilityChildren;
 -(NSArray <id<NSAccessibilityElement>> *)accessibilityChildrenInNavigationOrder;
 
+// NSTrackingArea overrides
+-(void)updateTrackingAreas;
 @end
 
 @interface SalFrameViewA11yWrapper : AquaA11yWrapper
diff --git a/vcl/osx/salframeview.mm b/vcl/osx/salframeview.mm
index 27c9e773ec4c..2c61416b9f03 100644
--- a/vcl/osx/salframeview.mm
+++ b/vcl/osx/salframeview.mm
@@ -2512,6 +2512,12 @@ -(NSArray *)accessibilityChildren
     return [self accessibilityChildren];
 }
 
+-(void)updateTrackingAreas
+{
+    [super updateTrackingAreas];
+    fprintf(stderr, "Tracking areas: %lu\n", [self.trackingAreas count]);
+}
+
 @end
 
 @implementation SalFrameViewA11yWrapper

I forgot to thank @libreoffice@cdhw.co.uk for the excellent "trackingArea" suggestion. I would have never thought of that as a possible cause.

Created attachment 190962 [details]
Simple spreadsheet used to demonstrate bug

(In reply to Patrick Luby from comment #12)
> I forgot to thank @libreoffice@cdhw.co.uk for the excellent "trackingArea"
> suggestion. I would have never thought of that as a possible cause.

You're welcome. "Ask me how I know..."

Anyway, I've done some more experimenting to see if I can find a recipe that reliably triggers the bug. Version numbers at the end of this message. I've attached the spreadsheet "Three Colours.ods" that I've been using. It was created from scratch for the test but otherwise there is nothing 'special' about it.

Open the spreadsheet and leave it displaying the 'red' sheet. Start dragging the lower right corner to resize the window and drag the corner around several small (say about 2cm diameter on the screen) circles a few times and then, without pausing or moving outside the window bounds, mouse-up and move the mouse into the window. On my machine this messes up the mouse state in the manner previously described as long as the mouse performs at least three 'orbits' and the mouse-up happens during the slingshot into the window.

Another comment about trackingAreas. Code using these can (and should) be significantly simpler than the trackingRect approach. This is because once you have attached the trackingArea to a view it is automatically resized when the view geometry changes. Also, the options available for trackingAreas make much of the fiddly housekeeping needed with trackingRects unnecessary.

(In reply to libreoffice from comment #14)
>Version numbers at the end of this message.

Version: 7.6.2.1 (AARCH64) / LibreOffice Community
Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333
CPU threads: 8; OS: Mac OS X 14.1.1; UI render: default; VCL: osx
Locale: en-GB (en_GB.UTF-8); UI: en-US
Calc: threaded

(In reply to libreoffice from comment #14)
> Open the spreadsheet and leave it displaying the 'red' sheet. Start dragging
> the lower right corner to resize the window and drag the corner around
> several small (say about 2cm diameter on the screen) circles a few times and
> then, without pausing or moving outside the window bounds, mouse-up and move
> the mouse into the window. On my machine this messes up the mouse state in
> the manner previously described as long as the mouse performs at least three
> 'orbits' and the mouse-up happens during the slingshot into the window.

Thank you for the steps. I can now reproduce the bug fairly reliable. The key is that I have to do the "circles a few times" within a second or two. Apparently, resizing the window slowly doesn't trigger the bug.

Anyway, I commented out all of the "add/removeTrackingRect:" calls in vcl/osx/salframe.cxx and that stops the bug from occurring in my local build. AFAICT, LibreOffice only uses tracking areas to get notified of mouseEntered: and mouseExited: events so I'll convert the existing code to the newer tracking area today and see if anything changes.

OK. I have upgraded LibreOffice to use the newer "tracking areas" selectors in the following patch. I will commit it once it passes unit tests:

https://gerrit.libreoffice.org/c/core/+/159845

In the meantime, I will continue testing as I suspect that my patch is not a complete fix and only eliminates the bug ~95% of the time.

Patrick Luby committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/54da842381ccb554d3cadc876f23cf183d21bf1a

tdf#155092 use tracking areas instead of tracking rectangles

It will be available in 24.2.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.

(In reply to Patrick Luby from comment #17)
> OK. I have upgraded LibreOffice to use the newer "tracking areas" selectors
> in the following patch. I will commit it once it passes unit tests:
> 
> https://gerrit.libreoffice.org/c/core/+/159845
> 
> In the meantime, I will continue testing as I suspect that my patch is not a
> complete fix and only eliminates the bug ~95% of the time.

OK. The above patch should be in tomorrow's (24 November 2023) nightly master build. If anyone can test it, please let me know if there are still any cases where you still see the bug.

The fix is now in the master nightly builds:

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

Note for testers: the master builds install in /Applications/LibreOfficeDev.app. These builds are not codesigned so you will need to execute the following Terminal command after installation:

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

Tested with:

Version: 7.6.2.1 (AARCH64) / LibreOffice Community
Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333
CPU threads: 8; OS: Mac OS X 14.1.1; UI render: default; VCL: osx
Locale: en-GB (en_GB.UTF-8); UI: en-US
Calc: threaded

and seems to have resolved issue.

The fix has exposed what might be the underlying cause. If I stress test by performing many very rapid 'resizing orbits' the window resizing stalls. The good news is that a mouse click in the window now selects the correct target cell without resizing and everything goes back to normal.

I'm not planning to report this as a bug as I don't think it will be an issue in practice. It might be worth keeping in mind as a 'clue' if other window management issues are reported in future.

I can now do my tax return without the window 'randomly' resizing every few minutes many thanks to Patrick.

(In reply to Charles Williams from comment #21)
> Version: 7.6.2.1 (AARCH64) / LibreOffice Community
> Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333
> CPU threads: 8; OS: Mac OS X 14.1.1; UI render: default; VCL: osx
> Locale: en-GB (en_GB.UTF-8); UI: en-US
> Calc: threaded

Hmmm. I haven't backported the fix to the LibreOffice 7.6 branch yet. So are you sure that you tested the master nightly build? Note: the master nightly build installs in /Applications as "LibreOfficeDev.app" instead of "LibreOffice.app".

Below is the info from LibreOffice's About dialog that I see (i.e version is 24.2)

Version: 24.2.0.0.alpha1+ (AARCH64) / LibreOffice Community
Build ID: 05d5181e2c19aca7e6098217ddb7065e02819a53
CPU threads: 8; OS: macOS 14.1.1; UI render: Skia/Raster; VCL: osx
Locale: en-CA (en_CA.UTF-8); UI: en-US
Calc: threaded

(In reply to Patrick Luby from comment #22)
> Hmmm. I haven't backported the fix to the LibreOffice 7.6 branch yet. So are
> you sure that you tested the master nightly build? Note: the master nightly
> build installs in /Applications as "LibreOfficeDev.app" instead of
> "LibreOffice.app".

My mistake, the version that I've verified as fixed is:

Version: 24.2.0.0.alpha1+ (AARCH64) / LibreOffice Community
Build ID: 05d5181e2c19aca7e6098217ddb7065e02819a53
CPU threads: 8; OS: macOS 14.1.1; UI render: default; VCL: osx
Locale: en-GB (en_GB.UTF-8); UI: en-US
Calc: threaded

(For the test, what I actually did was to launch both versions. I first checked 7.6 and it was buggy, then switched to 24.2 to prove it was fixed, then switched back to the still-running 7.6 to confirm that it was still faulty.)

(In reply to Charles Williams from comment #23)
> (For the test, what I actually did was to launch both versions. I first
> checked 7.6 and it was buggy, then switched to 24.2 to prove it was fixed,
> then switched back to the still-running 7.6 to confirm that it was still
> faulty.)

Thank you for double checking. It is good to hear that my fix works for you.

One side effect that I am seeing in the master nightly build that I don't see in my local build is that, at least with Skia enabled, my fix causes redrawing of the window content to be noticeable less frequent and sometimes doesn't finish redrawing before the next window resize starts a new redraw.

I am pretty sure that this is caused by attempt to reduce the amount of time stuck time in the native event dispatching loop in vcl/osx/salinst.cxx so next I will see if I can undo that part of my fix without causing this bug to reoccur.

While I am working on that, would it be possible to try to get a sample of LibreOffice using the /Applications/Utilities/Activity Monitor application when resizing fails? If you can get a sample after the resize fails but before you click in the window, it might tell me if LibreOffice is doing any "block and wait for next event" during live resizing. I fixed a few such cases but I wouldn't be surprised if there are a few more.

Unfortunately, the bug is still present on my intel MacBook Pro system:

Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 5fe2bf914c251009ec4709fa8fdc45c3b53f676b
CPU threads: 4; OS: macOS 13.6.1; UI render: Skia/Metal; VCL: osx
Locale: en-GB (en_GB.UTF-8); UI: en-US
Calc: threaded

I was testing with a new blank spreadsheet and the View > Graphics Output settings didn't seem to make a difference.

(In reply to Charles Williams from comment #25)
> Build ID: 5fe2bf914c251009ec4709fa8fdc45c3b53f676b

The build ID points to commmit 5fe2bf914c251009ec4709fa8fdc45c3b53f676b which was on 15 November 2023. It looks like you might have downloaded an older nightly build.

I see that in the master nightly build page below, macOS Intel has two x86_64 builds and one is dated 16 November 2023 so maybe (I hope) you accidently downloaded that one instead of the 24 November 2023 build just above it?

(In reply to Patrick Luby from comment #26)
> It looks like you might have downloaded an older nightly build.

Bingo. With the more recent build, the bug has gone:

Version: 24.2.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: 05d5181e2c19aca7e6098217ddb7065e02819a53
CPU threads: 4; OS: macOS 13.6.1; UI render: default; VCL: osx
Locale: en-GB (en_GB.UTF-8); UI: en-US
Calc: threaded

On this, relatively slow machine, the rendering of the spreadsheet during live-resizing is slow enough to see happening in real time. It looks to me as though the spreadsheet NSView is anchored to the bottom left of the NSWindow, which means the whole window area is being repeatedly redrawn during live resizing when only the cells along the bottom and right edges are being revealed/hidden.


It's getting late here, I will try to collect the stack samples requested in comment #24 tomorrow morning.

(In reply to Patrick Luby from comment #24)
> While I am working on that, would it be possible to try to get a sample of
> LibreOffice using the /Applications/Utilities/Activity Monitor application
> when resizing fails? If you can get a sample after the resize fails but
> before you click in the window, it might tell me if LibreOffice is doing any
> "block and wait for next event" during live resizing. I fixed a few such
> cases but I wouldn't be surprised if there are a few more.

I've not had success with this. I have noticed, however, that the lockup only seems to happen when 'Use Skia for all rendering' is enabled in the view preferences. I don't seem to be able to enable 'hardware acceleration' on my M1 Mac. (There is a grey symbol that might be a vertical key next to the checkbox, if that is significant.) To be honest, the 'View > Graphics Output' options have always been a bit of a mystery to me.

My impression, after testing with 'Quartz Debug / Tracking Areas' is that the trackingArea is working correctly. I'd be interested to know why you chose the 'NSTrackingActiveAlways' option as opposed to NSTrackingActiveWhenFirstResponder or NSTrackingActiveInKeyWindow but I doubt this will make any difference to the performance in practice.

(In reply to Charles Williams from comment #28)
> I've not had success with this. I have noticed, however, that the lockup
> only seems to happen when 'Use Skia for all rendering' is enabled in the
> view preferences. I don't seem to be able to enable 'hardware acceleration'
> on my M1 Mac. (There is a grey symbol that might be a vertical key next to
> the checkbox, if that is significant.) To be honest, the 'View > Graphics
> Output' options have always been a bit of a mystery to me.

I think you are seeing the same thing that I see. It really becomes obvious when you also check the "Force Skia software rendering" (i.e. Skia/Raster) checkbox in the Options dialog.

LibreOffice is not built for macOS which is probably why the View > Graphics Output setting is disabled. It is a Windows/Linux application that has been wired up to most of the time to behave close to a macOS native application. One of the "wired up" areas is that on macOS, LibreOffice does not draw content directly to windows because LibreOffice draws when it wants and does not wait for macOS draw drawing selectors to be called. So, LibreOffice has an offscreen buffer is explicitly flushed in -[NSView drawRect:] which works in most cases.

The problem here is that Skia has its own offscreen SkSurface that needs to be explicitly copied to the offscreen buffer and that copying is not happening nearly as frequently with Skia after my fix. Like the "wired up" window drawing, LibreOffice directly uses its own custom native event dispatch loop to filter/adjust/reorder the native events before they are passed on to the LibreOffice platform independent code.

I can turn this "Skia flush failure" during live resizing off undoing my changes to the native event dispatch loop, but then this bug starts reoccurring. Unfortunately, Apparently, LibreOffice posts an unknown number of native timers that need to fire to redraw the resized content so we have to do a run through LibreOffice's custom native event dispatch loop. I now believe that this is where this bug is occurring. Updating to the tracking area selectors was a good thing to do, but now we know that it isn't the cause of the bug.

So, now I am trying to find if there is a native event might the triggers this bug.

> 
> My impression, after testing with 'Quartz Debug / Tracking Areas' is that
> the trackingArea is working correctly. I'd be interested to know why you
> chose the 'NSTrackingActiveAlways' option as opposed to
> NSTrackingActiveWhenFirstResponder or NSTrackingActiveInKeyWindow but I
> doubt this will make any difference to the performance in practice.

NSTrackingActiveAlways delivers mouseEntered, mouseExited, and mouseMove events to unfocused windows like the older "tracking rect" selectors did.

(In reply to Patrick Luby from comment #29)
> So, now I am trying to find if there is a native event might the triggers
> this bug.

This bug is caused by an unexpected left mouse up event. Who knows what changes Apple made to live resizing, but when the bug occurs, LibreOffice's NSView gets a mouse up event. But when the bug doesn't occur, no mouse up event.

Anyway, I submitted the following hacky patch. It fixes this bug without breaking the repainting code. But!!!! When the bug occurs, instead of resizing the window in the next mouse down event, LibreOffice starts scrolling downward and to the right until you click somewhere in the window:

https://gerrit.libreoffice.org/c/core/+/159960

(In reply to Patrick Luby from comment #30)
> Anyway, I submitted the following hacky patch. It fixes this bug without
> breaking the repainting code. But!!!! When the bug occurs, instead of
> resizing the window in the next mouse down event, LibreOffice starts
> scrolling downward and to the right until you click somewhere in the window:
> 
> https://gerrit.libreoffice.org/c/core/+/159960

I will let this sit overnight because 1) it really seems bizarre that Apple does not stop the NSWindow's live resizing until the first mouse *down* event after mousing up. It probably works if you build your application on macOS from the ground up via NSViews, but it's clear that this confuses the LibreOffice backend that doesn't understand macOS' weird live resizing behavior.

I assume that on Windows and Linux, live resizing just generates a series of "window resized" events. I really don't like the weird behavior in the latest patch, so maybe I just need to call NSView's undocumented "end live resize" selector if we get a mouse up event during live resizing. Still, I hate invoking undocumented selectors because they inevitable change and I am just passing on the problem to some future developer.

(In reply to Patrick Luby from comment #30)
> This bug is caused by an unexpected left mouse up event. Who knows what
> changes Apple made to live resizing, but when the bug occurs, LibreOffice's
> NSView gets a mouse up event. But when the bug doesn't occur, no mouse up
> event.

I've just had a look at exactly how one of my own applications behaves. One point that I thought was interesting is that, depending on the precise location (with respect to the corner of the window) of the mouseDown that starts the resize, the sequence can be either:

mouseMoved
mouseEntered
mouseMoved
viewWillStartLiveResize
viewDidEndLiveResize
...
mouseExited

==== or ====

mouseMoved
viewWillStartLiveResize
viewDidEndLiveResize
mouseEntered
mouseMoved
...
mouseExited

In the former case, if I (accidentally?) click or double-click instead of dragging to resize I generate mouseDown/mouseUp event(s) inside the tracking area, which my application ignores. When the mouse is in the 'resize region' of the window corner the mouseDown event is not sent until the mouseUp event is sent.

Does the LO NSView use the NSWindow bounds to size its frame? I've been wondering what would happen if it were slightly too small.

Thank you for the description of how LO interfaces with AppKit in comment #29. It makes understanding what I'm seeing when using LO much easier.

LibreOffice's single NSView is set to the NSWindows content view so it autoresizes to the window's content area so I am seeing a lot of mouse dragged events during live resizing.

What is really different in LibreOffice is that in -[SalFrameWindow windowDidResize:] in vcl/osx/salframeview.mm we recurse into the native event dispatch loop to get the NSTimers that LibreOffice posts to the queue (see code snippets below):

    // Tell LibreOffice C++ code that window size has changed
    mpFrame->UpdateFrameGeometry();
    mpFrame->CallCallback( SalEvent::Resize, nullptr );

    // Recurse into the native event dispatch loop to get the NSTimers
    // that redraw the content that were posted in the above to fire
    Application::Reschedule( true );

Commenting out Application::Reschedule( true ) i.e. disable content repainting during live resizing, the bug stops occurring so I think odds are that recursing in the native event dispatch loop while we are in the middle of a native window resize event confuses macOS' live resizing code. I have an idea for eliminating this recursion by just firing any new paint timers immediately when in live resizing. Not sure how to do that yet.

Anyway, with this recursion, when the bug occurs I see a mouse up event while -[NSView inLiveResize] is still true. Then, it is in the next mouse down event that ends live resizing (and changing the window size) by calling the private -[NSWindow _endLiveResize] (see stacktrace snippet for mouse down event below). In my latest patch in commit 30, I was able to partially handle this recursion side effect by stopping resizing in -[SalFrameView windowWillResize:]. That stops the next mouse down from resizing the window, but the window contents look like you are dragging an ever-expanding down and to the right:

* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
  * frame #0: 0x00000001872d9178 AppKit`-[NSView _endLiveResize]
    frame #1: 0x00000001872d9250 AppKit`-[NSView _endLiveResize] + 216
    frame #2: 0x00000001872d9250 AppKit`-[NSView _endLiveResize] + 216
    frame #3: 0x00000001872d9250 AppKit`-[NSView _endLiveResize] + 216
    frame #4: 0x00000001872d9084 AppKit`-[NSView _endLiveResizeAsTopLevel] + 56
    frame #5: 0x00000001872d8f0c AppKit`-[NSWindow _endLiveResize] + 196
    frame #6: 0x000000018733af14 AppKit`-[NSWindow(NSWindowResizing) _resizeWithEvent:] + 2184
    frame #7: 0x000000018725ab0c AppKit`-[NSTitledFrame attemptResizeWithEvent:] + 156
    frame #8: 0x000000018725a924 AppKit`-[NSThemeFrame handleMouseDown:] + 196
    frame #9: 0x00000001872d0ac0 AppKit`-[NSThemeFrame mouseDown:] + 32
    frame #10: 0x00000001871ff18c AppKit`-[NSWindow(NSEventRouting) _handleMouseDownEvent:isDelayedEvent:] + 3472
    frame #11: 0x000000018718a690 AppKit`-[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] + 364
    frame #12: 0x000000018718a350 AppKit`-[NSWindow(NSEventRouting) sendEvent:] + 284
    frame #13: 0x0000000187833f30 AppKit`-[NSApplication(NSEventRouting) sendEvent:] + 1604

OK. I found a simple fix for this recursion into the native event dispatch loop during live resizing problem: I just stop dispatching native events (but the NSTimers still fire), until live resizing ends which occurs in the next mouse down:

https://gerrit.libreoffice.org/c/core/+/159960/2/vcl/osx/salinst.cxx#595

Patrick Luby committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/8a5da079592377cf69735973d922fc19e8ac763d

tdf#155092 don't dispatch left mouse up events during live resizing

It will be available in 24.2.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.

I committed my latest fix and it should be included in tomorrow's (28 November 2023) master nightly builds:

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

Note for testers: the master builds install in /Applications/LibreOfficeDev.app. These builds are not codesigned so you will need to execute the following Terminal command after installation:

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

I have uploaded a patch that backports the fix to the libreoffice-7-6 branch. I will wait to commit the backport patch for a few days for people to test the fix in the nightly master builds.

I still think the fix is a bit hacky but, unfortunately, LibreOffice will not repaint the content to match the new window size until a few NSTimers are fired. I tried just peeking at the native event queue and not dispatching any native events while live resizing, but then no new NSTimers were added.

The only way I have been able to get repainting during live resizing to work is to recurse into the native event dispatch loop and dispatch events until the next event in the queue is a mouse up event. At that point, no more native events will be dispatched until live resizing ends.

(In reply to Patrick Luby from comment #36)
> I committed my latest fix and it should be included in tomorrow's (28
> November 2023) master nightly builds:

Tested on a MacbookPro 13" (2017):

Version: 24.2.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: 38ef707aaf324bacba29401afb8bc113b19ad0ab
CPU threads: 4; OS: macOS 13.6.1; UI render: default; VCL: osx
Locale: en-GB (en_GB.UTF-8); UI: en-US
Calc: threaded

No sign of original bug. Redraw is a little bit laggy but is still a noticeable improvement on the redraw in the unfixed version (7.6.3.2).

(In reply to Patrick Luby from comment #37)
> I still think the fix is a bit hacky but, unfortunately, LibreOffice will
> not repaint the content to match the new window size until a few NSTimers
> are fired. I tried just peeking at the native event queue and not
> dispatching any native events while live resizing, but then no new NSTimers
> were added.

For me, the 'erratic mouse behaviour' was the priority. Having windows randomly resize and selections spontaneously start filling thousands of rows and columns in one window as a side effect of resizing another was infuriating. The fix seems to have dealt with all that.

On my 2017 MacBook Pro (Ventura) live resizing is a bit laggy but it was laggy in 7.6.3 and seems no worse to me in 24.02.

(In reply to Patrick Luby from comment #36)
> I committed my latest fix and it should be included in tomorrow's (28
> November 2023) master nightly builds:

Tested on an iMac 21.5" (2021) with three different 'View -> Graphics Output' settings:

----
Version: 24.2.0.0.alpha1+ (AARCH64) / LibreOffice Community
Build ID: 20cbe88ce5610fd8ee302e5780a4c0821ddb3db4
CPU threads: 8; OS: macOS 14.1.1; UI render: default; VCL: osx
Locale: en-GB (en_GB.UTF-8); UI: en-US
Calc: threaded

No sign of original bug. Redraw is slightly laggy. When reducing the view with an inward drag in a northwest direction (i.e. up and left) the row of tool-icons bounces up and down suggesting is being repainted a few mm too far down in the window and the overpainted in the correct position. This is probably a new bug bug it might be a low hanging fruit as you are currently immersed in this part of the code.
-----

-----
Version: 24.2.0.0.alpha1+ (AARCH64) / LibreOffice Community
Build ID: 20cbe88ce5610fd8ee302e5780a4c0821ddb3db4
CPU threads: 8; OS: macOS 14.1.1; UI render: Skia/Metal; VCL: osx
Locale: en-GB (en_GB.UTF-8); UI: en-US
Calc: threaded

No sign of original bug. Redraw is slightly laggy and flickers during resizing. The 'jumpy' tool-icons referred to above flicker slightly but don't jump during resizing.
-----

-----
Version: 24.2.0.0.alpha1+ (AARCH64) / LibreOffice Community
Build ID: 20cbe88ce5610fd8ee302e5780a4c0821ddb3db4
CPU threads: 8; OS: macOS 14.1.1; UI render: Skia/Raster; VCL: osx
Locale: en-GB (en_GB.UTF-8); UI: en-US
Calc: threaded

No sign of original bug. Redraws without the flickering and jumping of the other two settings. The redraw during live-resizing is not as smooth as a native single-platform app (e.g. Numbers.app) but is good enough not to be noticeable or distracting during actual use (as opposed to stress testing).
-----

I find it surprising that 'Force Kia software rendering' mode gives a better user experience than than the hardware-assisted options but M1 ARM64 processor seems to be fast enough for GPU acceleration not to be required.

My verdict: Ship it!


[tag] [reply] [−] Comment 39

(In reply to Charles Williams from comment #40)
> No sign of original bug. Redraws without the flickering and jumping of the
> other two settings. The redraw during live-resizing is not as smooth as a
> native single-platform app (e.g. Numbers.app) but is good enough not to be
> noticeable or distracting during actual use (as opposed to stress testing).
> -----
> 
> I find it surprising that 'Force Kia software rendering' mode gives a better
> user experience than than the hardware-assisted options but M1 ARM64
> processor seems to be fast enough for GPU acceleration not to be required.
> 
> My verdict: Ship it!

Thank you for the thorough testing. I only see the toolbar "jumping" when Skia is disabled but not when Skia is disabled. So, my guess is that the older "non-Skia" drawing code is flipping the veritical coordinates based on a cached window size and I just need to find where that is happening and update the cached values immediately before copying the LibreOffice offscreen buffer to the NSView. I am hopeful that I can fix the jumping problem pretty easily.

As for the flickering when using Skia/Metal (i.e. "Force Skia rending is unchecked"), I think it is due to a lag between when the NSWindow clears itself and the when the asynchronous LibreOffice drawing code finally executes. My wild guess is that, for some unkown reason, flushing a Skia/Metal SkSurface to an NSView isn't happening at the same pace/frequency of a Skia/Raster SkSurface. That sounds a lot trickier to fix than the Skia-disabled jumping bug.

So I'll see if I can fix the jumping bug in the next day or two and include it with the current fix in the next 24.2 alpha, 7.6.4, and 7.5.9 releases.

Patrick Luby committed a patch related to this issue.
It has been pushed to "master":

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

Related: tdf#155092 translate Y coordinate for height differences

It will be available in 24.2.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-6":

https://git.libreoffice.org/core/commit/fcccf586ba405008e4e3507f04fcd57bb2f18719

tdf#155092 don't dispatch left mouse up events during live resizing

It will be available in 7.6.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.

Patrick Luby committed a patch related to this issue.
> It has been pushed to "master":
> 
> https://git.libreoffice.org/core/commit/3b942f6efa8ffd11374031e4af8dbcb48a8962d1

Tested on an iMac 21.5" (2021) with three different 'View -> Graphics Output' settings:

----
Version: 24.2.0.0.alpha1+ (AARCH64) / LibreOffice Community
Build ID: 34fe1610cb98a7e57c6719a5d4f88d90a6c8752a
CPU threads: 8; OS: macOS 14.1.1; UI render: default; VCL: osx
Locale: en-GB (en_GB.UTF-8); UI: en-US
Calc: threaded

No sign of original bug or 'flickering'. Redraw is slightly laggy but only noticeable in the areas that have been revealed, which I find 'acceptable'. The row of tool-icons no longer bounces up and down when reducing the view with an inward drag in a northwest direction (i.e. up and left).

This seems to be the 'best' setting on this build/Mac combination.

----
Version: 24.2.0.0.alpha1+ (AARCH64) / LibreOffice Community
Build ID: 34fe1610cb98a7e57c6719a5d4f88d90a6c8752a
CPU threads: 8; OS: macOS 14.1.1; UI render: Skia/Metal; VCL: osx
Locale: en-GB (en_GB.UTF-8); UI: en-US
Calc: threaded

No sign of original bug. Redraw is slightly laggy and the whole view flickers during resizing. The 'jumpy' tool-icons referred to above flicker noticeably along with the rest of the view but don't jump during resizing.

I wouldn't use this setting for 'routine spreadsheeting' as I find flickering annoying (more so than lag).

----

----
Version: 24.2.0.0.alpha1+ (AARCH64) / LibreOffice Community
Build ID: 34fe1610cb98a7e57c6719a5d4f88d90a6c8752a
CPU threads: 8; OS: macOS 14.1.1; UI render: Skia/Raster; VCL: osx
Locale: en-GB (en_GB.UTF-8); UI: en-US
Calc: threaded

No sign of original bug or 'flickering'. Redraw is more laggy than the other two but only affects the areas that have been revealed, which I find 'acceptable'. The row of tool-icons no longer bounces up and down when reducing the view with an inward drag in a northwest direction (i.e. up and left).


This setting is better than the 'Skia/Metal' one. Performance is pretty much like the 
first 'default' setting but a the redraw is noticeably slower.
----

It is good news that the 'default' settings are also the best from all points of view. In my experience, Mac end-users rarely use anything other than the default settings.

These improvements have had a very positive impact. Working on spreadsheets is going to be much less frustrating in the future.

I'll repeat the tests on my 2017 MacBook Pro tonight.

Thank you for your thorough testing. I missed the deadline for the 24.02 Alpha 1 release, but my fixes should be included in the 24.02 Alpha 2 and 7.6.4 and a future 7.5.x releases.

I have opened a bug 158461 for the Skia/Metal flicker. I probably won't be able to investigate that bug anytime soon, but I don't want to forget about it.

Tested on a 2017 MacBook Pro (Ventura) with three different 'View -> Graphics Output' settings:

----
Version: 24.2.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: 3b942f6efa8ffd11374031e4af8dbcb48a8962d1
CPU threads: 4; OS: macOS 13.6.1; UI render: default; VCL: osx
Locale: en-GB (en_GB.UTF-8); UI: en-US
Calc: threaded

No sign of original bug or 'flickering'. Redraw is noticeably laggy (delays of up to  ca 0.5s) but only in the areas that have been revealed, which I find 'acceptable'. The row of tool-icons no longer bounces up and down when reducing the view with an inward drag in a northwest direction (i.e. up and left).

This seems to be the 'best' setting on this build/Mac combination.

----
Version: 24.2.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: 3b942f6efa8ffd11374031e4af8dbcb48a8962d1
CPU threads: 4; OS: macOS 13.6.1; UI render: Skia/Metal; VCL: osx
Locale: en-GB (en_GB.UTF-8); UI: en-US
Calc: threaded

No sign of original bug. Redraw is slightly laggy and the whole view flickers perceptably during resizing. Also, the exposed areas are black before being painted (in light grey), which makes them more distracting. The 'jumpy' tool-icons referred to above flicker noticeably along with the rest of the view but don't jump during resizing.

I probably wouldn't use this setting for 'routine spreadsheeting' as I don't like flickering but it is snappier than the 'default' setting.

----

----
Version: 24.2.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: 3b942f6efa8ffd11374031e4af8dbcb48a8962d1
CPU threads: 4; OS: macOS 13.6.1; UI render: Skia/Raster; VCL: osx
Locale: en-GB (en_GB.UTF-8); UI: en-US
Calc: threaded

No sign of original bug or 'flickering'. Redraw behaviour and lag seem very similar to the 'defaults' behaviour above. The row of tool-icons no longer bounces up and down when reducing the view with an inward drag in a northwest direction (i.e. up and left).

This setting is better than the 'Skia/Metal' one. Performance is pretty much like the 
first 'default' setting.
----

On this x86_64, it is possible to select the 'Use hardware acceleration' check box but it doesn't seem to have any effect and is cleared by restarting LO.

Thank you for the detailed test results. Marking this bug as verified/fixed since the resizing on mouse down bug appears to be fixed.

*** Bug 157498 has been marked as a duplicate of this bug. ***