Bug Hunting Session
Bug 75471 - Newly opened LibO document frames stay in background (i. e. LibO does not get focus)
Summary: Newly opened LibO document frames stay in background (i. e. LibO does not get...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
4.2.1.1 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:5.4.0 target:5.3.0 target:5.2.6
Keywords: bibisectRequest, regression
: 85717 89912 94129 94747 96011 105708 106816 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-02-24 21:38 UTC by Luca
Modified: 2018-11-25 07:42 UTC (History)
27 users (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 Luca 2014-02-24 21:38:41 UTC
1) Open a LibreOffice document (Writer, Calc) and minimize it

2) Open an Explorer window, or any file manager, and use it to launch another LibreOffice document

The second LibreOffice document runs maximized but stays in background, doesn't get the focus.

The first LibreOffice document to be launched, opens in foreground regularly.
Comment 1 Maxim Monastirsky 2014-02-25 10:31:37 UTC

*** This bug has been marked as a duplicate of bug 48300 ***
Comment 2 Mikeyy - L10n HR 2014-06-19 11:25:30 UTC
This shouldn't be marked as duplicate of bug 48300 when it's not same problem.
Bug reported here is REGRESSION. It worked as expected in LibreOffice 4.1.
Bug 48300 never worked that way and was reported for LibreOffice 3.5.1 more then 2 years ago.

Wanted to report this my self, but luckly found it's already reported. I switched to 4.2 from 4.1 week ago, and this annoys hell out of me.
Comment 3 Maxim Monastirsky 2014-06-19 12:24:59 UTC
(In reply to comment #2)
> This shouldn't be marked as duplicate of bug 48300 when it's not same
> problem.
Sorry but I don't get the difference. The reproduction steps and the result seems identical to me. Can you clarify please what exactly the difference?
Comment 4 Mikeyy - L10n HR 2014-06-19 12:46:00 UTC
Difference is, one in regression, other one is maybe enhancement (or bug, however you take it).

Bug 48300 talks about window focus when opening already open file for second time.

So:
1. Open windows explorer, maximise it so it shows full screen.
2. Open 1.ods - ODS window opens in focus (FOREGROUND), windows explorer isn't visible any more, it's in background
3. Bring windows explorer in foreground, maximised
4. Open 2.ods:
          - in 4.1 - ODS window opens in focus (FOREGROUND), windows explorer isn't visible any more, it's in background
          - in 4.2 - ODS window opens in BACKGROUND (not visible), windows explorer is still visible (this bug 75471)
5. From windows explorer open 1.ods again, same one you opened in step 2. (this is bug 48300)

As far as I can see, bug 48300 is fixed. With 4.2 double opened window open in foreground.
My configuration is LO 4.2.5.2 on Windows 7 64bit
Comment 5 Tomi Javanainen 2014-08-09 18:31:08 UTC
Confirmed
LO Version: 4.2.5.2
OS Win 8.1 Pro 64bit
Comment 6 Hanni Bunii 2014-09-05 21:34:41 UTC
Same here with 4.2.6.2 on Windows 7.
Comment 7 Teodor Constantinescu 2014-10-13 17:22:36 UTC
Same issue here, 4.2.5.2, Windows 7.
Comment 8 Maxim Monastirsky 2014-11-01 17:52:11 UTC
*** Bug 85717 has been marked as a duplicate of this bug. ***
Comment 9 MisterNeutron 2014-11-04 19:20:43 UTC
I'm seeing this as well, with 4.2.6.3 on fully-patched Win7/64. Simple way to reproduce:

1) open Windows Explorer
2) pull to one side so that the window occupies half the monitor width
3) double-click on whatever.ods
4) LibreOffice launches and opens whatever.ods maximized, but it remains behind Windows Explorer
5) Clicking on LibreOffice doesn't bring it to the front. Only closing Windows Explorer allows you to see whatever.ods.
Comment 10 tommy27 2014-11-04 19:28:39 UTC
don't change version field. it must indicate earliest version the bug has been seen
Comment 11 billy78 2014-11-05 17:06:59 UTC
(In reply to MisterNeutron from comment #9)
> I'm seeing this as well, with 4.2.6.3 on fully-patched Win7/64. Simple way
> to reproduce:
> 
> 1) open Windows Explorer
> 2) pull to one side so that the window occupies half the monitor width
> 3) double-click on whatever.ods
> 4) LibreOffice launches and opens whatever.ods maximized, but it remains
> behind Windows Explorer
> 5) Clicking on LibreOffice doesn't bring it to the front. Only closing
> Windows Explorer allows you to see whatever.ods.

I can confirm this (Win7 x64). Since I installed the first stable of 4.2 (and for all versions since that), if I double-click a file (odt, ods, odp), I see the splash screen of LO, but then explorer comes in front and LO goes behind it. This doesn't happen all the time, but quite often and it very frustrating! It's a bit different from the bug report of the OP, since it happens without having any other LO document opened and minimized.
Comment 12 Heiko Tietze 2014-12-15 12:21:24 UTC
Same for Linux (4.3.4.1) but not nightly build (4.5.0.0.alpha0+). I changed the target platform to "all".
Comment 13 Heiko Tietze 2014-12-18 09:31:52 UTC
4.3.2.2 and 4.3.4.1 under Windows 7 work as expected. No problems with z-order or focus.
Comment 14 Mikeyy - L10n HR 2014-12-18 10:36:22 UTC
(In reply to Heiko Tietze from comment #13)
> 4.3.2.2 and 4.3.4.1 under Windows 7 work as expected. No problems with
> z-order or focus.

I'm pretty sure that's not true. I use 4.3.5 and it's not coming into focus.

Open windows explorer, open 1 file, LO should come into focus. Now go back to windows explorer, open second file. LO doesn't come into focus, it stays in background.
Comment 15 Luca 2014-12-18 10:40:28 UTC
(In reply to Heiko Tietze from comment #13)
> 4.3.2.2 and 4.3.4.1 under Windows 7 work as expected. No problems with
> z-order or focus.

I run 4.3.4.1 under Windows 7 64 Home Premium. The bug is here and it's very very annoying. Did you follow the steps to reproduce as described?
Comment 16 Heiko Tietze 2014-12-18 11:37:18 UTC
I know what happens from Linux. We talked about this issue at the UX meeting yesterday. It's a bug and we can push to get it solved as most annoying, or we wait until 4.5 (nightly build works for me on Linux; haven't tried 4.4).

To double check OS: W7 Enterprise SP1, 64bit; ver reports "Microsoft Windows [Version 6.1.7601]"
Comment 17 Carsten 2015-02-04 09:44:03 UTC
This issue still exists.
Tested versions are 4.3 and 4.4.

Is it complicated to fix this problem?
We just migrated our sales department from MS Office to LO.
They are not very excited about the conversion.
But this issue is really annoying if you
work with several documents at the same time.


LO Version: 4.4.0.3
OS: Windows 8.1 including all available updates
same with Windows 7, Windows Server 2008 R2, Windows Server 2012 R2
Comment 18 Murz 2015-02-20 12:45:08 UTC
Got the same problem on Kubuntu 14.10 with LibreOffice 4.4 release. Is there any workaround exists for this problem?
Comment 19 Luca 2015-03-01 13:08:39 UTC

*** This bug has been marked as a duplicate of bug 48300 ***
Comment 20 Tobias Leupold 2015-04-06 08:17:41 UTC
Duplicate or not, I see the same on Gentoo Linux on KDE. This is not a severe bug, but it's annoying. Would be nice if you fixed this.
Comment 21 cyberduck 2015-05-11 10:26:53 UTC
Same here
LO Version: 4.4.3.2
OS Win 8.1 64bit
Comment 22 tommy27 2015-09-19 06:58:02 UTC
(In reply to Luca from comment #19)
> 
> *** This bug has been marked as a duplicate of bug 48300 ***

I revert status to NEW since as Mikeyy - L10h HR said in comment 2, though similar, these focus issues are not exactly the same bug...

Bug 48300 is about not getting focus after clicking twice in the file explorer on an already opened file

Bug 75471 is about not getting focus after clicking other files in the file explorer
Comment 23 tommy27 2015-09-19 07:01:46 UTC
*** Bug 89912 has been marked as a duplicate of this bug. ***
Comment 24 Buovjaga 2015-09-19 07:44:05 UTC
Bug 94129 was different, though. It was about not having opened LibO before. I don't repro that behavior, but I do repro the behavior of bug 89912 and bug 75471.
Comment 25 tommy27 2015-10-04 07:31:21 UTC
*** Bug 94747 has been marked as a duplicate of this bug. ***
Comment 26 Luca 2015-11-09 11:32:30 UTC
This is still affecting 5.0.3.2, Windows 7 Home Premium 64.
Comment 27 Tiziana Marchionni 2016-01-19 16:18:42 UTC
Still affecting 5.0.4
Comment 28 Luca 2016-02-10 16:12:44 UTC
Still present in 5.1.0.3
Comment 29 Tobias Leupold 2016-02-10 16:16:39 UTC Comment hidden (obsolete)
Comment 30 Tareef 2016-02-15 15:27:49 UTC
same problem with Debian 8
Libreoffice 4.3.3.2
KDE 4.14.12
Comment 31 V Stuart Foote 2016-06-28 15:34:17 UTC
On Windows 10 Pro 64-bit en-US with
Version: 5.2.0.1 (x64)
Build ID: fcbcb4963bda8633ba72bd2108ca1e802aad557d
CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; 
Locale: en-US (en_US)

Issue of bug 48300 is fixed. An already open document takes focus from Windows Explorer shell when selected.

Issue here, apparently affecting all platforms, that initially opening a document does not receive LibreOffice docshell focus--is not yet correct. Nor is the outlier Windows issue of bug 94129
Comment 32 Luca 2016-06-29 19:26:41 UTC
Still here in v. 5.2.0.1.
Comment 33 hiro 2016-09-09 13:21:42 UTC Comment hidden (obsolete)
Comment 34 Luca 2016-09-09 16:14:43 UTC Comment hidden (obsolete)
Comment 35 Luca 2016-09-09 16:16:59 UTC Comment hidden (obsolete)
Comment 36 Luca 2016-09-09 16:20:14 UTC Comment hidden (obsolete)
Comment 37 Luca 2016-09-09 16:23:23 UTC Comment hidden (obsolete)
Comment 38 Xisco Faulí 2016-09-12 12:36:23 UTC
Adding keyword 'bibisectRequest'.
Comment 39 them4z+odflo 2016-11-09 15:24:21 UTC
We're seeing this bug on openSUSE Leap 42.1, KDE 5.21.0, LO 5.1.5.
Comment 40 skrogul 2016-11-15 22:13:45 UTC Comment hidden (me-too)
Comment 41 Robert Gonzalez MX 2017-01-04 04:00:38 UTC
Hi. Tested with Version: 5.2.4.2
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 is still reproducible.

It is also related to bug 49134
Comment 42 Samuel Mehrbrodt (CIB) 2017-01-13 13:58:23 UTC
*** Bug 96011 has been marked as a duplicate of this bug. ***
Comment 43 Samuel Mehrbrodt (CIB) 2017-01-13 14:38:21 UTC
Pushed a fix (used wrong bug number):

Samuel Mehrbrodt committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=08316e7b2fd913dc20f9477d161b48d8e676a9bb

tdf#96011 Document is not focused when opening a second window

It will be available in 5.4.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 44 Mikeyy - L10n HR 2017-01-13 18:36:58 UTC
Any chance of backporting this to eminent 5.3 release or even 5.2?
Comment 45 Samuel Mehrbrodt (CIB) 2017-01-13 20:52:54 UTC
(In reply to Mikeyy - L10n HR from comment #44)
> Any chance of backporting this to eminent 5.3 release or even 5.2?

Sure but before I'd like someone to verify that the issue is indeed fixed (use the daily builds as described in comment 43).
Comment 46 Mikeyy - L10n HR 2017-01-14 10:39:57 UTC
(In reply to Samuel Mehrbrodt (CIB) from comment #45)
> Sure but before I'd like someone to verify that the issue is indeed fixed
> (use the daily builds as described in comment 43).

It's harder for me to test it on my windows machine which already has LO5.2 installed, but it seams to me fix isn't working.

1. Opened windows explorer and found few xls files.
2. Right click, open with, and choose scalc.exe from LibreDev directory.
3. XLS file opened.
4. Returned to windows exporer and repeat point 2. again on new file.

Result: New file didn't open in foreground, it opened in background.

If I repeat all this, but NOT WITH scalc.exe, instead I choose soffice.exe, second file opens in foreground like it should be.
Comment 47 Mikeyy - L10n HR 2017-01-14 10:50:46 UTC
(In reply to Mikeyy - L10n HR from comment #46)

> Result: New file didn't open in foreground, it opened in background.

Let me just clarify this further.
2nd file opened above 1st file, and if I open 3rd file, it will open above 1st and 2nd file. So basicly, LO is opening files in foreground, but just in relation to other opened LO files.

What it is not doing is opening it in foreground in relation to all other programs (windows explorer, thunderbird or any other mail client etc.).
Comment 48 Buovjaga 2017-01-14 13:34:25 UTC
(In reply to Mikeyy - L10n HR from comment #47)
> (In reply to Mikeyy - L10n HR from comment #46)
> 
> > Result: New file didn't open in foreground, it opened in background.
> 
> Let me just clarify this further.
> 2nd file opened above 1st file, and if I open 3rd file, it will open above
> 1st and 2nd file. So basicly, LO is opening files in foreground, but just in
> relation to other opened LO files.
> 
> What it is not doing is opening it in foreground in relation to all other
> programs (windows explorer, thunderbird or any other mail client etc.).

I don't know, which version you tested with as you didn't say, but this is false at least in my tests. Please always copy and paste to a comment the Help - About window contents. If your 5.4 build was not this, the fix was not in it: http://dev-builds.libreoffice.org/daily/master/Win-x86@42/2017-01-14_04.20.03/libo-master~2017-01-14_04.20.03_LibreOfficeDev_5.4.0.0.alpha0_Win_x86.msi

I tested first with 5.2.4 to verify I can see the bug in my Win 10 VM. I tested with Luca's steps in the description.

Then I uninstalled 5.2.4, installed the latest master build and associated LibO documents with it.

The documents DO go over Windows explorer windows now, contrary to how it behaved with my 5.2.4 test. With 5.2.4, the 2nd LibO window was left behind the Win explorer window, unfocused. Now it jumps above it, focused.

The behavior is consistent as I keep opening more documents.

As far as I'm concerned, this can be marked FIXED, but maybe we will wait for more test results.

Version: 5.4.0.0.alpha0+
Build ID: 9e7526044c8fa6b006b0cb791d15f2476c96ebf2
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-01-14_04:20:03
Locale: fi-FI (fi_FI); Calc: group
Comment 49 Mikeyy - L10n HR 2017-01-14 14:20:31 UTC
(In reply to Buovjaga from comment #48)
> I don't know, which version you tested with as you didn't say, but this is
> false at least in my tests. Please always copy and paste to a comment the
> Help - About window contents. If your 5.4 build was not this, the fix was
> not in it:
> http://dev-builds.libreoffice.org/daily/master/Win-x86@42/2017-01-14_04.20.
> 03/libo-master~2017-01-14_04.20.03_LibreOfficeDev_5.4.0.0.alpha0_Win_x86.msi

Download msi today from this link:
http://dev-builds.libreoffice.org/daily/master/Win-x86@42/current/libo-master~2017-01-14_04.20.03_LibreOfficeDev_5.4.0.0.alpha0_Win_x86.msi
Comment 50 Samuel Mehrbrodt (CIB) 2017-01-16 07:46:22 UTC
Btw you can also apply the fix by going to Tools->Options->Advanced->Expert Configuration.
Search for 'ForceFocusAndToFront' and double click to change it to 'true'.

This should work in all affected versions.
Comment 51 Mikeyy - L10n HR 2017-01-16 12:31:18 UTC
(In reply to Samuel Mehrbrodt (CIB) from comment #50)
> Btw you can also apply the fix by going to Tools->Options->Advanced->Expert
> Configuration.
> Search for 'ForceFocusAndToFront' and double click to change it to 'true'.
> 
> This should work in all affected versions.

Yes, that works with LO 5.2.4.2
I guess it should work with other versions also then.
Comment 52 eBatch 2017-01-22 18:38:14 UTC
Have tested this in 5.1.5.2 and 5.2.4.2 (using Tools->Options->Advanced->Expert Configuration; search for 'ForceFocusAndToFront' and double click to change it to 'true').

Seems to work fine. Begs the question as to how long this fix has been around but not publicised (or am I missing something?)?

Also why isn't ForceFocusAndToFront set as true by default (or will it be in 5.4)?

But thanks for fix anyhow.
Comment 53 Xisco Faulí 2017-01-22 23:08:16 UTC
Closing as RESOLVED VERIFIED as per comment 52
Comment 54 Xisco Faulí 2017-01-22 23:08:49 UTC
Closing as VERIFIED FIXED as per comment 52
Comment 55 Luca 2017-01-22 23:49:13 UTC
(In reply to eBatch from comment #52)
> Have tested this in 5.1.5.2 and 5.2.4.2 (using
> Tools->Options->Advanced->Expert Configuration; search for
> 'ForceFocusAndToFront' and double click to change it to 'true').
> 
> Seems to work fine. Begs the question as to how long this fix has been
> around but not publicised (or am I missing something?)?

I did that in 5.3.0.2 (Italian version) and it works.

I can't believe that! This problem has been haunting me since 2013.

> Also why isn't ForceFocusAndToFront set as true by default (or will it be in
> 5.4)?

I second that, of course. Why not? Why was it ever modified in the first place? There was no such a problem before 2013, AFAIR.
Comment 56 Aron Budea 2017-01-23 01:29:39 UTC
(In reply to eBatch from comment #52)
> Seems to work fine. Begs the question as to how long this fix has been
> around but not publicised (or am I missing something?)?

Apparently:
https://bz.apache.org/ooo/show_bug.cgi?id=99971

Somewhat related stuff:
https://bugs.documentfoundation.org/show_bug.cgi?id=35091#c9
Comment 57 Samuel Mehrbrodt (CIB) 2017-01-23 07:39:29 UTC
(In reply to eBatch from comment #52)
> Seems to work fine. Begs the question as to how long this fix has been
> around but not publicised (or am I missing something?)?
> 
> Also why isn't ForceFocusAndToFront set as true by default (or will it be in
> 5.4)?

I found it when I tried to track this bug down. Someone changed [1] it (in LibreOffice code instead of his own settings) in 2013 to fit his personal preference, and it seems nobody really noticed.

It is now true by default after the fix.

[1] https://cgit.freedesktop.org/libreoffice/core/commit/?id=fa52e16b3fb1b8b051f8f64a52c126ba3cbf4d54
Comment 58 eBatch 2017-01-23 08:54:21 UTC
(In reply to Samuel Mehrbrodt (CIB) from comment #57)
> 
> I found it when I tried to track this bug down. Someone changed [1] it (in
> LibreOffice code instead of his own settings) in 2013 to fit his personal
> preference, and it seems nobody really noticed.
> 

Makes one wonder what other "dangerous" changes have crept in by a back door!
Comment 59 Timur 2017-01-23 13:42:45 UTC
Looks like a simple change, and since this is a regression, please consider backport to 5.3.0.3 which is the first official 5.3 so there would be no change between releases.
Comment 60 V Stuart Foote 2017-01-23 15:54:33 UTC
(In reply to Samuel Mehrbrodt (CIB) from comment #57)
> 
> It is now true by default after the fix.
> 

Yes but isn't that configuration value set only for Windows, unx and macosx have no configuration setting and presumably OS/DE will treat it with the default "false" [1][2] and any mishandling of z-order is an OS/DE Windows manager issue and not a LibreOffce issue.

This issue should have remained Windows only as while setting the default back to true for Windows with https://cgit.freedesktop.org/libreoffice/core/commit/?id=08316e7b2fd913dc20f9477d161b48d8e676a9bb you've restored the original Windows only configuration implemented for OOo 3.2 [3].

But a user electing to set ForceFocusAndToFront "true" via Expert configuration on Linux or macOS will be bypassing OS/DE behavior--we've not changed that.

Would agree that a backport of the Windows configuration toggle to "true" to 5.3 should be benign. Probably too late for 5.2

=-refs-=

[1] http://opengrok.libreoffice.org/xref/core/framework/source/loadenv/loadenv.cxx?a=true#1623

[2] http://opengrok.libreoffice.org/xref/core/officecfg/registry/schema/org/openoffice/Office/Common.xcs?a=true#2620

[3] https://cgit.freedesktop.org/libreoffice/core/commit/?id=23740dc4a7e81c8c5129e26fe579cf81363d6388


Backports are up for review
5.3 -- https://gerrit.libreoffice.org/#/c/33271/
5.2 -- https://gerrit.libreoffice.org/#/c/33276/
Comment 61 Commit Notification 2017-02-01 13:40:38 UTC
Samuel Mehrbrodt committed a patch related to this issue.
It has been pushed to "libreoffice-5-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=26804e7534cb969b1b542cb0e89664a1215f9d42&h=libreoffice-5-2

tdf#75471 Document is not focused when opening a second window

It will be available in 5.2.6.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 62 Aron Budea 2017-02-05 02:51:12 UTC
*** Bug 105708 has been marked as a duplicate of this bug. ***
Comment 63 joachim.krecher 2017-02-05 16:53:00 UTC Comment hidden (obsolete)
Comment 64 joachim.krecher 2017-02-05 16:54:57 UTC Comment hidden (obsolete)
Comment 65 joachim.krecher 2017-02-05 17:01:42 UTC
(In reply to Samuel Mehrbrodt (CIB) from comment #50)
> Btw you can also apply the fix by going to Tools->Options->Advanced->Expert
> Configuration.
> Search for 'ForceFocusAndToFront' and double click to change it to 'true'.
> 
> This should work in all affected versions.

By the way in the German version of LO instead of "Tools . . ." you have to select "Extras", then "Optionen... Alt+F12", there the first menu "LibreOffice", there "Erweitert", there on the right side down "Experteneinstellungen öffnen". Here you have to make use of the empty line ending by "Suchen", enter there ForceFocusAndToFront (with no empty space at the end!), hit ENTER-key (or click "Suchen"), then double-click the new line
"NewDocumentHandling  ForceFocusAndToFront ..."
so that "false" is replaced by "true", then click "OK" and after closing of this window again "OK".

All these special configurations are kept in the file named
   registrymodifications.xcu
which is located in
   C:\Users\%USER%\AppData\Roaming\LibreOffice\4\user
LO does not seem to write these data to the Windows Registry, rather in the file just mentioned. To have a convenient look at this file one can make use of any program suitable for xml-pages, as e.g. InternetExplorer or Firefox.

You can open this file - while LibreOffice is NOT running! - e.g. in Windows Editor. It will take some seconds until the whole file is read and "edited"; so please wait. Then find there the line containing "ForceFocusAndToFront" and change manually "false" (found between <value> and </value>) into "true", then save the file.
Comment 66 Mike Kaganski 2017-02-16 02:07:03 UTC
As mentioned on AskLibO https://ask.libreoffice.org/en/question/60935/documents-open-in-background-lo-doesnt-take-focus-win-7/?answer=87734#post-id-87734:

> ForceFocusAndToFront = true did not completely work for me unfortunately.
> When I open a CSV file (or similar) and it first pops up with a window
> asking how to do the import, that window still remains in the background.
> New windows that open up without that initial dialog seem to be ok however,
> but the ones that have that dialog are still problematic.
Comment 67 Mikeyy - L10n HR 2017-02-16 06:06:01 UTC
(In reply to Mike Kaganski from comment #66)
> As mentioned on AskLibO
> https://ask.libreoffice.org/en/question/60935/documents-open-in-background-
> lo-doesnt-take-focus-win-7/?answer=87734#post-id-87734:
> 
> > ForceFocusAndToFront = true did not completely work for me unfortunately.
> > When I open a CSV file (or similar) and it first pops up with a window
> > asking how to do the import, that window still remains in the background.
> > New windows that open up without that initial dialog seem to be ok however,
> > but the ones that have that dialog are still problematic.

That's true, but if I remember correctly, it's that way since OO times.
It should be corrected, but not in this bug. This bug is solved.

Again, thank you Samuel for fix.
Comment 68 Aron Budea 2017-03-28 16:24:05 UTC
*** Bug 106816 has been marked as a duplicate of this bug. ***
Comment 69 Gitsy 2017-03-29 14:15:53 UTC
still exists in Version: 5.3.1.2
Comment 70 Gitsy 2017-03-29 14:16:28 UTC Comment hidden (obsolete)
Comment 71 joachim.krecher 2017-03-30 09:58:11 UTC
The problem can be solved ALSO IN LibreOffice VERSION 5.3.2.2 (x64) (Build-ID: e80a0e0fd1875e1696614d24c32df0f95f03deb2)in the same way as described in earlier comments (either by using one of LO's menus or by manually changing the file registrymodifications.xcu)!
Comment 72 joachim.krecher 2017-03-30 09:59:49 UTC
Sorry: in comment 71 the version number should be "5.3.1.2", not "5.3.2.2"
Comment 73 V Stuart Foote 2017-03-30 12:02:39 UTC
No the window focus is correct on Windows builds.

The "ForceFocusAndToFront" value is set "True" by default with a clean user profile. It can be set from Expert Configuration dialog. Tools -> Options -> Advanced: Open Expert Configuration button (as localized). Or manually opening the LibreOffice registry "registrymodifications.xcu" with an XML editor, if present in the .xcu for the profile--either True/False--the value had been edited at some point and it is not a default profile. Clear the user profile.

If with a clean user profile, and verifying the "ForceFocusAndToFront" value is set True via the Expert Configuration if the window focus and "to front" is not correct then please file a new BZ issue. Provide full OS and Desktop details and Steps to Reproduce.

Thanks!
 

=-testing-=

Windows 10 Pro 64-bit en-US

Version: 5.3.1.2 (x64)
Build ID: e80a0e0fd1875e1696614d24c32df0f95f03deb2
CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; Layout Engine: new; 
Locale: en-US (en_US); Calc: group
Comment 74 Gitsy 2017-03-30 12:57:15 UTC
the ForceFocusAndToFront is set to true. 
but still, if the file has macros- the security dialogue opens in background.

Version: 5.3.1.2
Build ID: 1:5.3.1-0ubuntu1~yakkety0
Comment 75 V Stuart Foote 2017-03-30 13:31:48 UTC
(In reply to Gitsy from comment #74)
> the ForceFocusAndToFront is set to true. 
> but still, if the file has macros- the security dialogue opens in background.
> 
> Version: 5.3.1.2
> Build ID: 1:5.3.1-0ubuntu1~yakkety0

Fine, but believe that is going to be the same underlying OS issue as bug 49134 or similar. Please write the issue up there or in a new bug.

This is FIXED.
Comment 76 Buovjaga 2018-01-27 08:36:57 UTC
*** Bug 96011 has been marked as a duplicate of this bug. ***
Comment 77 V Stuart Foote 2018-01-27 15:00:26 UTC
*** Bug 94129 has been marked as a duplicate of this bug. ***
Comment 78 zian rizky 2018-11-25 07:42:30 UTC Comment hidden (spam)