On Windows 7, without previously having run any libreoffice components since booting windows:
1) browse to a folder containing any libreoffice files, e.g. .ods spreadsheet
2) double-click on a file to open it
3) the appropriate libreoffice program runs, the icon is on the windows taskbar, but windows explorer is still the top-level window
The libreoffice component should run with its window on top. It doesn't, which is annoying. You have to click its icon on the taskbar.
This also happens with non-LO files you've associated e.g. .csv files.
AFAIK this problem has been present in all previous releases of OpenOffice & LibreOffice on windows.
Note that if you've already run a LibreOffice program since booting windows, the problem doesn't occur.
Additional info: I have LO configured for quicker startup, but I don't think this affects the bug.
Windows 7 Professional 64-bit, Intel Core i5 CPU, 8 GB RAM
May be a duplicate of 89912
As far as I remember this bug appeared after 4.4 (4.3 was OK)
*** This bug has been marked as a duplicate of bug 89912 ***
reverting status according to this comment:
edited summary notes
Alan, Yan: are you still seeing this with the latest version? I could reproduce the other variety, but never this.
I will test when I'll be near Windows machine (in a week maybe)
I can confirm this still occurs in
Build ID: f99d75f39f1c57ebdd7ffc5f42867c12031db97a
Windows 7 64-bit
I've just installed this, restarted Windows, & reproduced it.
BTW I've looked in Control Panel, Programs & Features & I don't see 'Java' anywhere. I assume LO has its own copy somewhere.
Please let me know if you need any more information or diagnostics.
still there in LibO 18.104.22.168?
I have tested this bug with Version: 22.214.171.124
Build ID: 3d5603e1122f0f102b62521720ab13a38a4e0eb0
CPU Threads: 8; OS Version: Windows 6.2; UI Render: default;
Locale: es-MX (es_MX); Calc: group
On Windows 10
And found that only the first file opened with LO goes to foreground and focus.
Going back to the windows explorer and double clicking other files, will open behind the windows explorer.
This is some what related to bug 49134
There was a fix to a related bug, maybe you guys could test: http://dev-builds.libreoffice.org/daily/master/Win-x86@42/current/
It's different behaviour, but the bug still occurs.
Here's what I've done:
(1) install suggested alpha release
(2) restart windows
(3) open windows explorer (Win + E)
(4) browse to folder containing spreadsheet
(5) double click on spreadsheet
(6) spreadsheet opens, & Calc is correctly in the foreground
(7) close Calc
(8) close windows explorer
(9) open windows explorer again
(10) browse to folder containing spreadsheet
(11) double click on same spreadsheet as before
(12) file opens, but Calc is *not* in the foreground this time.
Further info: after installation, I *didn't* configure LO to pre-load during start up.
Hope this helps you diagnose the problem further. Please ask if you need any more info
I have a slightly different variant (using Windows 10):
1) Open Windows Explorer in full screen mode and navigate to a folder containing spreadsheet documents
2} Double-click on a document and Calc opens the document in focus. Note that the Windows taskbar shows the Calc icon underlined to indicate that a document is open
3) Switch back to Windows Explorer and double-click another document. Nothing appears to happen. However, in the Windows taskbar a new LibreOffice icon briefly opens then closes, and the Calc icon shows a double underline to indicate that more than one document is open.
4) Hover over the Calc icon in the taskbar and Windows shows two documents open. Click on the new one and it will come into focus.
The problem is worse if you then try to open a CSV file through Windows Explorer. There is no indication at all that anything has happened. If you hover over the Calc icon it still shows only the documents that were previously opened. However, if you click on the last document that was opened you will see that it has a "Text import" dialog box open that allows you to open the CSV file
Alan's comment 11 matches Robert's comment 9. Adjusting summary and changing status to NEW.
(In reply to Alan Rouse from comment #12)
> The problem is worse if you then try to open a CSV file through Windows
> Explorer. There is no indication at all that anything has happened. If you
> hover over the Calc icon it still shows only the documents that were
> previously opened. However, if you click on the last document that was
> opened you will see that it has a "Text import" dialog box open that allows
> you to open the CSV file
This is a known old issue: bug 32935
I have tested it on Windows XP and Windows 10, and my comment is that with the change in the ForceFocusAndToFront property to true, all the LO files open to foreground except the ones that are password protected.
The enter password dialog displays behind windows explorer.
(In reply to Robert Gonzalez MX from comment #14)
> I have tested it on Windows XP and Windows 10, and my comment is that with
> the change in the ForceFocusAndToFront property to true, all the LO files
> open to foreground except the ones that are password protected.
> The enter password dialog displays behind windows explorer.
Aha.. so the behavior mentioned in your comment 9 is no longer true? If yes, then it interestingly conflicts with Alan Rew's experience.
To make things explicit, please always copy and paste the contents of your Help - About box. Now I am not 100% certain Alan tested with a dev build as I have not seen it with my own eyes.
Using OP's revised STR comment 11 or comment 12 -- can not reproduce.
On Windows 10 Home 64-bit en-US with
Version: 126.96.36.199 (x64)
Build ID: d2bec56d7865f05a1003dc88449f2b0fdd85309a
CPU threads: 4; OS: Windows 10.0; UI render: GL;
Locale: en-US (en_US); Calc: CL
Seems clear that Samuel's work on bug 75471 for setting default "ForceFocusAndToFront" back to True for Windows builds resolved this at 5.2.6, 5.3 and 5.4 [refs]
The ForceFocusAndToFront control remains False for unx and osx, so OS/DE continues to control app frame focus there for better or worse. With some residual work needed for bug 32935, bug 49134, bug 114466 and the like.
*** This bug has been marked as a duplicate of bug 75471 ***