Please disregard comment 1. I reproduce with Version: 6.0.3.2
Build ID: 1:6.0.3-0ubuntu1
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); Calc: group

*when a spreadsheet is open* prior to double-clicking a CSV (just as OP mentioned in description).

I can't reproduce it in

Versió: 6.0.6.2
ID de la construcció: 1:6.0.6-0ubuntu0.16.04.1
Fils de CPU: 4; SO: Linux 4.15; Renderitzador de la IU: per defecte; VCL: gtk3; 
Configuració local: ca-ES (ca_ES.UTF-8); Calc: group

I have a spreadsheet already open and the dialog is prompted on top...

OTOH, I can reproduce it if I have the extension manager open and I open a CSV file in LibreOffice.... Similar to bug 119645

Can reconfirm (why was the previous bug closed?) on Version: 6.0.7.3 Build ID: 1:6.0.7-0ubuntu0.18.04.2 gtk3. 

In 18.04 I have a new non-deterministic bug: sometimes a dock icon on the left side panel is not created at all, if the first file you open is csv and the icon is not locked to the dock (not in "Favorites"): an icon is initially created for the import dialog but then disappears when you press OK, and does not reappear on opening any other files - this leaves just "alt+tab" for navigation an memomorizing what you have opened (or requires to keep Calc in "Favorites").

Good question.

I have tried to report this issue on antoher thread to also have it closed. 

This is why I don't report bugs. It is a waste of my time

Previous report on Bug 32935 : 
We are past the 8 year mark on this bug.

I hit it multiple times a day on Ubuntu 18.04.02 LTS using LibreOffice 6.0.7.3

Open LibreOffice open with cvs file (first file opens fine)
Select another csv file to open.
Import screen doesn't get focus.
Import screen is buried somewhere on desktop. (Must minimize all active windows to find.)

It happily lets you to try to open the same file again (giving you another buried import screen).


Note: Way back in 2010 there was a company willing to sponsor the fixing of this bug. So super annoying to see the bug report closed while people continue to report the issue.

here I see someone has also linked that bug report and it is still marked as fixed. Not fised as on 2019-07-02 on Ubuntu 18.10 and LibreOffice 6.1.6.3.

(In reply to Miranda from comment #6)
> here I see someone has also linked that bug report and it is still marked as
> fixed. Not fised as on 2019-07-02 on Ubuntu 18.10 and LibreOffice 6.1.6.3.
The other bug report was specifically opened on an issue encountered in Windows, which has been fixed since. Just because the symptoms are similar, it doesn't mean the cause is the same, and mixing different issues is really unhelpful for those willing to tackle one. Please consider their time as well.

On the other hand this bug report is certainly open.

> I hit it multiple times a day on Ubuntu 18.04.02 LTS using LibreOffice
> 6.0.7.3
Version 6.0.7.3 is EOL, and will not receive updates (except perhaps security updates ported by Canonical). The current version is 6.2.4, with 6.3.0 beta 2 also available for testing.

For all of those encountering this baffling and difficult behaviour, there is a way to resolve this simply! Thank goodness!

I found the instructions in the link below worked for me (pasted below also for posterity):

https://ask.libreoffice.org/en/question/56043/make-dialog-windows-get-focus/

I'm using LibreOffice Calc (Version: 4.4.5.2).

I saw that various dialog windows (but not all) mostly did not get focus when they opened. I needed to alt+tab them or to mouse-click within the dialog window.

Then I came across an answer which entails setting Tools > Options > View > Mouse > Mouse positioning to "Dialog center". That works perfectly for me.

But why does it work? Does Mouse positioning to "Dialog center" incorporate a "click" to make the dialog window active? And shouldn't the default be to have a dialog window in focus as soon as it opens?

(In reply to Jesse McNichol from comment #8)

Thanks Jesse McNichol, works for me.
The real solution would be to fix the code.

Since it's a workaround, not an actual fix, let's keep the bug open.

There's another case I can reproduce, it's not the same, but perhaps there's similarity, and it can be checked from the terminal with any version:
- in a terminal window, in a LO installation directory, run ./soffice
- in another terminal window, try to open a CSV from the terminal eg. ./soffice <CSV with location>

=> The splash screen will be shown, and persist, and the CSV import dialog will be opened in the original soffice instance, but it doesn't get focus.

I am also having this bug (KDE Neon 20.04, which is also Ubuntu based).

However, in the search results where I found the link to this issue, I also found  bug 119815, which looks like a duplicate of this one. Interestingly, the opener seems to have found the offending commit: <https://cgit.freedesktop.org/libreoffice/core/commit/?id=1092cc0c75f6d2ab649dd31b1db9f0a9f0944355>

Probably worth investigating? (Especially considering that bug 119815 did not get any non-automatic answer yet... )

Moreover, I would like to point to another unfortunate side effect under KDE Plasma desktop environment: if the first libreoffice window was already opened in some other activity*, not only the CSV import dialog will not be focused, but also it will open in the activity of the first libreoffice window instead of current activity (expected behavior).

Probably the window manager considers the CSV import dialog as a child window of the existing window (which it should definitely not be!).

*: activities are a KDE-centric feature comparable to virtual desktops. I did not try to reproduce the behavior in the case where the first libreoffice window was opened in the same activity but different virtual desktop yet, but I expect a similar result (be it with kwin or another window manager).

(In reply to Aldric Degorre from comment #11)
> I am also having this bug (KDE Neon 20.04, which is also Ubuntu based).
> 

Hi Aldric - I recently switched to KDE Neon 20.04 and can confirm that the behaviour you're describing with activities occurs for me too. A simple workaround is to open a LibreOffice calc empty window in the current activity prior to opening my tsv. This way your dialog at least stays on the right activity but it does add an annoying additional step.

But I did find a way to bypass this awful behaviour through a bit of googling and looking at the related windows thread (https://bugs.documentfoundation.org/show_bug.cgi?id=32935). In that one, user John Griessen posted a potential workaround to bypass this csv/tsv dialog box from even opening but it doesn't work for KDE Neon. But then I came across this stackoverflow thread:

https://stackoverflow.com/questions/64073090/using-libreoffices-scalc-to-convert-tab-delimited-text-to-excel-from-the-comm

In it, the poster provides a piece of code that works to bypass the dialog box:

libreoffice --calc --infilter="Text - txt - csv (StarCalc):9,39,76,2,1/9"

In Dolphin, you can just right-click on a class of files (in my case TSV), click "Properties" > "File Type Options" > Under "Application Preference Order" Libreoffice calc should be at the top, so click it then "Edit" > go to "Application" tab, then just paste the above text before the "%U" (replacing whatever's there, e.g. "libreoffice --calc". Now it works for me to open tsv files directly from the file browser - they stay in the proper activity because the dialog box is never spawned.

Doesn't actually fix the bug but it does make LibreOffice usable with TSV files and multiple activities. Hopefully it helps someone.

Actually my workaround needs one more addition: If you do it exactly as I suggested in KDE, then "ods" files will be opened with the same flag which causes an input/output error. So the way I've got it working is to add a terminal command as the default program for TSV files. That seems to work and preserves .ods file associations so they're still opened with Libreoffice Calc using default parameters.

Another minor correction:

libreoffice --calc --infilter="Text - txt - csv (StarCalc):9,39,76,1,"

Otherwise, the first row and column will be cut off. You can change the comma-separated values to suit your use case.

Dear Jesse McNichol,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug