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.
*** This bug has been marked as a duplicate of bug 48300 ***
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.
(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?
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
Confirmed LO Version: 4.2.5.2 OS Win 8.1 Pro 64bit
Same here with 4.2.6.2 on Windows 7.
Same issue here, 4.2.5.2, Windows 7.
*** Bug 85717 has been marked as a duplicate of this bug. ***
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.
don't change version field. it must indicate earliest version the bug has been seen
(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.
Same for Linux (4.3.4.1) but not nightly build (4.5.0.0.alpha0+). I changed the target platform to "all".
4.3.2.2 and 4.3.4.1 under Windows 7 work as expected. No problems with z-order or focus.
(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.
(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?
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]"
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
Got the same problem on Kubuntu 14.10 with LibreOffice 4.4 release. Is there any workaround exists for this problem?
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.
Same here LO Version: 4.4.3.2 OS Win 8.1 64bit
(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
*** Bug 89912 has been marked as a duplicate of this bug. ***
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.
*** Bug 94747 has been marked as a duplicate of this bug. ***
This is still affecting 5.0.3.2, Windows 7 Home Premium 64.
Still affecting 5.0.4
Still present in 5.1.0.3
On Gentoo, this is fixed with Version 5.0.3.2.
same problem with Debian 8 Libreoffice 4.3.3.2 KDE 4.14.12
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
Still here in v. 5.2.0.1.
still here in 5.1.4.2
Still here in 5.2.1.2
Adding keyword 'bibisectRequest'.
We're seeing this bug on openSUSE Leap 42.1, KDE 5.21.0, LO 5.1.5.
I can confirm this behavior on a freshly installed debian stable with KDE. Observed behavior: newly opened libreoffice document stays in background. Expected behavior: document should open in foreground (get focus) Quite annoying, if working in a production environment. Debian 8 stable Libreoffice 4.3.3.2 KDE SC 4.14.12
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
*** Bug 96011 has been marked as a duplicate of this bug. ***
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.
Any chance of backporting this to eminent 5.3 release or even 5.2?
(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).
(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.
(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.).
(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
(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
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.
(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.
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.
Closing as RESOLVED VERIFIED as per comment 52
Closing as VERIFIED FIXED as per comment 52
(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.
(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
(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
(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!
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.
(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/
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.
*** Bug 105708 has been marked as a duplicate of this bug. ***
(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. Probably this is the easiest way to get LibreOffice to be foregrounded after a file is double-clicked in Windows Explorer. 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.
(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.
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.
(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.
*** Bug 106816 has been marked as a duplicate of this bug. ***
still exists in Version: 5.3.1.2
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)!
Sorry: in comment 71 the version number should be "5.3.1.2", not "5.3.2.2"
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
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
(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.
*** Bug 94129 has been marked as a duplicate of this bug. ***
https://www.jualtasmurahbbs.com/ tas murah bandung yogyakarta klik foto untuk melihat detil produk tas ransel tas ransel wanita tas ransel murah tas ransel laptop harga tas ransel jual tas ransel tas ransel eiger tas ransel bodypack tas ransel pria tas https://www.jualtasmurahbbs.com/category/tas-sekolah-anak/ jual tas sekolah grosir tas lokal grosir online bandung menjual tas model terbaru toko tas online grosir tas lokal wanita jual sd, smp, sma, kuliah, baik laki laki maupun perempuan sd, smp, sma, kuliah, baik laki https://www.jualtasmurahbbs.com/category/kipling/ tas kipling murah berkualitas berbagi macam merk terkenal seperti bao bao charles and keith gucci hermes victoria beckham dan masih banyak lagi grosir tas ransel wanita branded jual tas murah online tas online berkualitas https://www.jualtasmurahbbs.com/category/tas-ransel-wanita/ tas ransel wanita bandung toko online jual tas tas branded kw super grosir tas murah harga terjangkau kualitas import kw super premium pengiriman dari batam ke indonesia toko tas online menjual tas branded tas wanita grosir https://www.jualtasmurahbbs.com/category/tote-bag/ tas tote bag murah untuk anda lipat ketika anda tidak menggunakan tas jual tas militer online tas lebanon industri peralatan tas tangan motif army belanja tas tangan army tas lebanon biasa digunakan para tni untuk https://www.jualtasmurahbbs.com/category/cath-kidston/ jual cath kidston murah harga dibawah wanita tas kw wanita tas import kw wanita tas super wanita tas semi premium tas super premium diatas tas kantor tl elle tas tambahan model toko online jual ragam tas handbag https://www.jualtasmurahbbs.com/category/anello/ tas anello asli atau heels sembarangan akan membuat handbag kalian cepat rusak dan kotor distributor tas batam resmi kabizaku distributor tas batam tas dompet distributor tas batamkabizaku distributor tas batam https://www.jualtasmurahbbs.com/category/jansport/ online shop jual tas jansport murah tas ransel tas sekolah tas wanita tas wantita murah toko tas online tas wanita whoopees tote bag biru konveksi tas tote bag tangerang konveksi tas tangerang konveksitangerang terbaru
This bug was never fixed. I've seen this happen consistently on every computer every day for several years now. Specifically, a new window in LibreOffice is unfocused about 80-90% of the time, regardless of whether it's the first window opened. I'm currently seeing this in v7.0.2.2 on Ubuntu 20.04.
It most certainly was fixed and has remained so for OPs Windows builds. Other os/DE crept into the BZ. In general reopening a Closed Fixed "TLDR;" BZ issue like this does no one any good. Please file a well described new issue and if insistent refer back here.
Setting to VERIFIED as it was before it got reopened
The issue still persists in Version: 6.4.7.2 Build ID: 1:6.4.7-0ubuntu0.20.04.4 on KDE Neon 5.24. No other application suffers from such a bug, only LibreOffice.
(In reply to Maxim Egorushkin from comment #83) > The issue still persists in Version: 6.4.7.2 Build ID: > 1:6.4.7-0ubuntu0.20.04.4 on KDE Neon 5.24. > > No other application suffers from such a bug, only LibreOffice. 1. Test with 7.3 2. If it still persists, create a new bug report
LibreOffice(In reply to Buovjaga from comment #84) > (In reply to Maxim Egorushkin from comment #83) > > The issue still persists in Version: 6.4.7.2 Build ID: > > 1:6.4.7-0ubuntu0.20.04.4 on KDE Neon 5.24. > > > > No other application suffers from such a bug, only LibreOffice. > > 1. Test with 7.3 > 2. If it still persists, create a new bug report This bug doesn't occur in 7.3.1, thank you.