Bug 61768 - macOS does not recognise LO dialog windows for standalone screenshots
Summary: macOS does not recognise LO dialog windows for standalone screenshots
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other macOS (All)
: low trivial
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: macOS-UI-polish
  Show dependency tree / graph
 
Reported: 2013-03-03 23:56 UTC by Emir Sarı
Modified: 2023-03-23 18:52 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Emir Sarı 2013-03-03 23:56:12 UTC 
Hello,

As most Mac users know, OS X allows user to take custom screen shots by pressing CMD+Shift+4, showing a cross-hair and when pressing "SPACE" on this state, it allows user to take a screen shot of just the active window with nice formatting. 

When I try to do this with a LO dialogue window open, instead just selecting the active dialogue window, OS X selects the whole LO window, not recognising the active LO dialogue box. 

This works fine with every other Mac application I've tried, but just not Libreoffice. Thus Libreoffice lacks the ability to present its dialogues as separate dialogue boxes.

I wonder if this is the result of the new method for creating dialogue boxes, so if anyone could confirm this on 3.6 or earlier versions, that'd be great. 

OS X 10.7.5 LO 4.0.1.2
Comment 1 steve 2013-03-04 00:47:25 UTC 
10.8.2 LO 4.0.1.2 I can confirm the problem reported by Emir.
Comment 2 Dennis Roczek 2013-08-05 11:46:32 UTC 
I can confirm that for OS X 10.7 and LibO 4.1.0.4.
Comment 3 Emir Sarı 2013-11-18 10:03:09 UTC 
I think this is related to fact the modal dialogs are not really modal on OS X.
Comment 4 QA Administrators 2015-04-19 03:23:18 UTC Comment hidden (obsolete)
Comment 5 steve 2016-05-08 07:47:03 UTC 
Valid as ever with latest master

Version: 5.2.0.0.alpha1+
Build ID: ee5850893e15acda1d7ce7cf17da7c80f2fa810a
CPU Threads: 4; OS Version: Mac OS X 10.11.4; UI Render: default; 
TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2016-05-06_00:59:44
Locale: de-DE (de.UTF-8)
Comment 6 Julien Nabet 2016-07-03 09:59:11 UTC 
On MacOs 10.11.5 with LO 5.1.4, I tried this:
- Launch Impress
- Try so save the brand new empty file
=> it dialog box displays
- Cmd Shift 4
=> haircross appears
- type Space
=> dialog box is selected and haircross is replaced by a camera
- click left button mouse
=> a new file appears on MacOs desktop corresponding to only dialog box

Could someone give a step by step more precise so it could be reproduceable more easily?
Comment 7 Alex Thurgood 2016-09-01 12:20:34 UTC 
Confirming on

Version: 5.2.0.4
Build ID: 066b007f5ebcc236395c7d282ba488bca6720265
CPU Threads: 2; OS Version: Mac OS X 10.11.6; UI Render: default; 
Locale: en-GB (fr.UTF-8)
Comment 8 Alex Thurgood 2016-09-01 12:23:31 UTC 
Julien, try this :

Start LO
Open the About dialog (LibreOffice > About Libreoffice)
Press Cmd-Shift-4
Move the crosshair to be positioned over the About dialog
Press spacebar key
Left mouse button click

A screenshot of the whole application window is taken.
Comment 9 Julien Nabet 2016-09-02 19:34:06 UTC 
(In reply to Alex Thurgood from comment #8)
> Julien, try this :
> 
> Start LO
> Open the About dialog (LibreOffice > About Libreoffice)
> Press Cmd-Shift-4
> Move the crosshair to be positioned over the About dialog
> Press spacebar key
> Left mouse button click
> 
> A screenshot of the whole application window is taken.

Cmd-Shift-4 doesn't make any crosshair appear for me.
(I suppose these:
"Cmd" is the key to the left of space bar
"Shift" is the key above "fn" key (left bottom corner)
)
I supposed I missed something but I don't know what since shortcuts config (from Spotlight) shows it.
Comment 10 Xisco Faulí 2017-09-29 08:53:28 UTC Comment hidden (obsolete)
Comment 11 eisa01 2018-06-15 22:09:53 UTC 
This is still present, been the case since LO 3.3 so inherited from OOo

Lowering importance as this is a trivial bug

Version: 6.2.0.0.alpha0+
Build ID: b292a27698e85fd9d60c03613c3b0c67835c4dc1
CPU threads: 2; OS: Mac OS X 10.12.6; UI render: default; 
TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2018-06-06_23:25:55
Locale: en-US (en_US.UTF-8); Calc: group threaded
Comment 12 QA Administrators 2019-06-16 02:58:01 UTC Comment hidden (obsolete)
Comment 13 eisa01 2019-08-10 20:09:07 UTC 
Still present

Version: 6.4.0.0.alpha0+
Build ID: 54028dc503fc08eb12e287919d5e2850cff05b73
CPU threads: 4; OS: Mac OS X 10.14.6; UI render: default; VCL: osx; 
TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2019-07-31_01:48:19
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded
Comment 14 QA Administrators 2021-08-10 03:48:48 UTC Comment hidden (obsolete)
Comment 15 Emir Sarı 2021-08-10 05:53:51 UTC 
Still valid.
Comment 16 João Gomes 2023-03-22 20:18:24 UTC 
I have to add that besides this issue with screenshots, and with screenshots looking corrupted if you move the modal window away from the main document window, there's the added undesirable effect of not being able to functionally move a modal window to a secondary display when using Mission Control and separate spaces for each screen.

When in that configuration, moving any modal window to a display other than the one containing the parent, document window results in the modal window becoming invisible/inaccessible. By activating regular or App Exposé you can indeed see the window exists, but the only way to leave this modal state and fix the issue is by pressing the Escape or Enter key to close the window (and opening it again if needed).

This situation is inevitable, as macOS obscures any parts of a window that lie outside of its parent display/space and how LibreOffice is effectively treating the parent window/modal window combo as a single window/Z-axis layer, and also has the added detrimental effect, besides being bad UX, in potentially resulting in lost input data (if the user presses Escape) or inputting undesirable data (if the user blindly presses Enter without being able to select tabs to check their inputs before committing to potential changes).
Comment 17 João Gomes 2023-03-23 18:52:12 UTC 
I will also add that there are two potential solutions to this issue, each with its own advantages and drawbacks.

Solution #1: Transforming ALL modal windows into macOS-HIG-compliant, floating modal panes (they essentially replaced the old Mac OS X Aqua's “sheets”, that slid from under the parent document window's titlebar, and are simple floating windows *without* a titlebar or its corresponding close–minimize–fullscreen/zoom traffic-light buttons).

Advantages: the development team gets to keep the current behaviour (but still has to fix bug 31915, obviously, though maybe that bug would go away all by itself just by virtue of using the proper APIs?), while fixing the screenshot issue *and* also the secondary display issue by outright preventing users from separating modal windows from their parent document windows.

Disadvantages: the solution involves more coding, and precludes the advantages of Solution #2 (see below).


Solution #2: Keeping ALL modal windows as they are, while fixing this bug (maybe selecting them can still automatically bring the parent document window into focus, so as not to confuse the user over what window they belong too, but they must become then become divorced from them and no longer move along with them or resting on the same z-axis plane, and instead on the plane immediately above their respective parent document windows), *and* make the parent document windows scrollable even while a modal window is opened.

Advantages: the development team gets to keep the current look (and, again, still has to fix bug 31915, there's no way around it), while likely having to write less code. Also, multiple screen layouts receive extra support, as modifying the parameters on a modal window and consecutively pressing the “Apply” button, while being able to see its effects on the then unobstructed parent document window is especially useful (bonus points for implementing scrollability of parent document windows while modal windows are open, as it further enhances the functionality of this state).

Disadvantages: less compliance with the HIG, and potentially the need to write more code and do more testing on what effectively means more changes to functionality overall.