Problem description: The undo action (shortcut, menu or button triggered) doesn't always refresh the text. Steps to reproduce: 1. New presentation 2. Select the "Title, Content" layout on the right 3. With the mouse, place cursor in the content box to enter text at the first (and only) bullet 4. Enter a bunch of random alpha characters (no carriage return) 5. Trigger the edit/undo action. 6. The undo doesn't change the text 7. Change window focus or click anywhere in the left "Slides" pane, or any big action which triggers a full refresh of the slide viewport. 8. observe that the undo did occur now that the view is refreshed. Current behavior: The text is not refreshed. Expected behavior: It should refresh... Operating System: Mac OS X Version: 4.3.0.4 release
Works for me as described in your report on same LO version as you.
(In reply to comment #1) > Works for me as described in your report on same LO version as you. Made a video: https://drive.google.com/folderview?id=0B-AMxW_pZfvkSmFGS1AtekRuLXc&usp=sharing I only used the mouse to cause the undo, note that when the text box refreshes and the line disappears, it's because I click in the text box which seems to cause a draw refresh. The auto-spell check doesn't seem to have any effects. Could it have anything to do with keyboard layout? Or presence of ~/Library/KeyBindings/DefaultKeyBinding.dict ? I'm just thinking out loud here. Version: 4.3.0.4 Build ID: 62ad5818884a2fc2e5780dd45466868d41009ec0 Mac OS 10.9.4
I just discovered it may has something to do with a tiling helper program I use (BetterTouchTool). It seems that the behaviour is correct until I hit one of my keyboard shortcuts which resizes the window to quadrants or halves of the screen. LibreOffice's refresh is essentially broken until I quit and restart it (a new window with a new presentation remains affected, an actual quit is required). I will try to contact BetterTouchTool to get feedback. Do you guys see anything on your end? FYI: http://www.boastr.net (the tool)
Ah, thanks for video, I was undoing via toolbar button, which works. so the problem is in the menu Edit - Undo
(In reply to comment #4) > Ah, thanks for video, I was undoing via toolbar button, which works. so the > problem is in the menu Edit - Undo Nope, scratch that, I can still undo via the edit menu, so this works for me.
Yeah, the method of undo has no impact. I confirmed that the problem appears after the auto-resize as demonstrated here: https://drive.google.com/file/d/0B-AMxW_pZfvkSmNsTUIta3hDUUk/edit?usp=sharing You can see the proper behaviour first, and then once the window is auto-resized, the undo happens, but fails to refresh the text until you force a refresh somehow (by clicking around).
Your tiling tool could effectively be causing a disconnect between the main app window and the menu commands until a drawpage refresh is called, but this could be LO's fault, I guess it would depend on the methods called and whether LO is supposed to behave nicely with other tiling apps.
I've changed the title to reflect your findings
Unfortunately, as I don't have the tile manager in question, I can not reproduce the behaviour.
In LO, tiling is managed via VCL as far as I know, which is possibly not fully Apple API compliant.
(In reply to comment #9) > Unfortunately, as I don't have the tile manager in question, I can not > reproduce the behaviour. It's free at the URL posted above in comment 3, and well worth discovering for all it's features. Once you have it running, click it's icon in the top right menu, select preferences, then Keyboard tab, then the '+' to add a new shortcut, in the bottom part, enter your shortcut on the left, and under "Trigger Predefined Action", choose a "Window Resize & Move" like "Maximize window left" or some other similar action. Enjoy.
Unfortunately, I'm not going to be instaling some random third party application that affects window management in my system. We don't state that we support 3rd party software that affects system behaviour, so this is unlilely to get fixed, unless accidentally. It is already a hard enough job for the developers to try and keep up with Apple's own API which changes every version. I'm inclined to set this to WONTFIX or NOTOURBUG
(In reply to Alex Thurgood from comment #12) I'm certain the random tool merely exposes some incorrect usage of the system's API or missing event subscription to detect window size change... And that the bug would most likely express itself again if any system initiated window resize (from the point of view of libreoffice) were to occur. That is any window manager on osx is likely to throw off libreoffice. What I think is unfortunate is no one bothered to 'confirm' the issue. Being a developer myself, I know the preciousness of a 100% reproducible issue and the potential it has to shed light over unsuspected bugs. With this scenario, some things might have been learned here, and prevent further obscure behaviour (which I know exist). ... but, c'est la vie.
@Jeff : yes, it is unfortunate, but we don't have the manpower resources to test every possible display setup with every possible OSX display manager addon/substitute. There are already known window resizing display bugs with LO and naked OSX alone, our code uses older API's which quite possibly are deprecated relative to the calls that the tool you are using implements, but we simply don't have the resources to chase them all down. Setting as NOTOURBUG.