Bug 82871 - EDITING: text rendering not refreshed on undo with active third party tiling manager
Summary: EDITING: text rendering not refreshed on undo with active third party tiling ...
Status: RESOLVED NOTOURBUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
4.3.0.4 release
Hardware: Other macOS (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-20 14:30 UTC by jeff.dagenais
Modified: 2015-01-18 13:20 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description jeff.dagenais 2014-08-20 14:30:20 UTC
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
Comment 1 Alex Thurgood 2014-09-30 15:21:45 UTC
Works for me as described in your report on same LO version as you.
Comment 2 jeff.dagenais 2014-10-01 12:53:06 UTC
(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
Comment 3 jeff.dagenais 2014-10-01 13:02:36 UTC
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)
Comment 4 Alex Thurgood 2014-10-01 13:14:37 UTC
Ah, thanks for video, I was undoing via toolbar button, which works. so the problem is in the menu Edit - Undo
Comment 5 Alex Thurgood 2014-10-01 13:16:49 UTC
(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.
Comment 6 jeff.dagenais 2014-10-01 13:18:55 UTC
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).
Comment 7 Alex Thurgood 2014-10-01 13:31:10 UTC
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.
Comment 8 Alex Thurgood 2014-10-01 13:33:28 UTC
I've changed the title to reflect your findings
Comment 9 Alex Thurgood 2014-10-01 13:34:28 UTC
Unfortunately, as I don't have the tile manager in question, I can not reproduce the behaviour.
Comment 10 Alex Thurgood 2014-10-01 13:36:44 UTC
In LO, tiling is managed via VCL as far as I know, which is possibly not fully Apple API compliant.
Comment 11 jeff.dagenais 2014-10-01 13:46:30 UTC
(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.
Comment 12 Alex Thurgood 2015-01-16 14:11:33 UTC
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
Comment 13 jeff.dagenais 2015-01-17 13:38:58 UTC
(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.
Comment 14 Alex Thurgood 2015-01-18 13:20:57 UTC
@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.