Description: Usually, downloads when opened appear on top of what's already running, but LO downloads frequently appear underneath open apps, usually on top of an instance of LO. (Would be better if they popped the app to the top.) This time, no LO apps were open, and I couldn't find the import dialog (what's the separator, etc.) so I found the downloaded file and tried to open it. I was informed the document was already in use elsewhere (but I still couldn't find it). I was finally able to retrieve the file, but only after the third try and telling LO to ignore the invisible instance. Steps to Reproduce: 1. I didn't try to reproduce; I just soldiered on. 2. 3. Actual Results: Good! Expected Results: get my work done ...and after momentary frustration (typical with ANY computer app) I could. Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36
@Michael : I'm sorry, but I have no idea what you are talking about. How is a failed download of mysql LibreOffice's fault ? You talk about a document being in use elsewhere, which document do you mean ? Please provide repeatable, detailed steps relating to your problem so that we can at least try to reproduce/confirm/deny, etc Setting to NEEDINFO, please set back to UNCONFIRMED once you have provided the detailed steps to reproduce, and if this involves a particular document, please provide a copy of that document, scrubbed of any confidential information, and which shows the issue you are having.
Firstly, Alex, I wasn't blaming anybody, but this is clearly an LO fail. So far as I know, it's a one-timer. I have not seen it before or since ...but it was stubborn and threw LO into a loop that was hard to get out of. When one downloads a CSV file from a MySQL host via browser, it triggers an LO intake form that seeks to know the delimiter and other csv parsing info. Here's a constant bug on my Win7 system that I have also experience on my Win10 system: if LO is already running -- any module -- the intake form appears on top of the latest instance of LO running, but NOT on top of everything running. Normally, I would expect an active query like this to pop the summoned app to the top. If one isn't familiar with this "feature," one can easily think -- my clients often do -- that their download hasn't happened correctly, and do it again, and again, and again. It would be nice if LO popped the intake form to the top of the desktop stack. While I hate Excel, I do note that it does pop itself properly. This LO trait causes client consternation and resistance to adopt LO. Back to this particular bug: I had been editing an LO document with write, but had closed it. Because of the way I opened it (from a blank LO write document) the blank LO write doc was still alive, but buried beneath other apps. When I downloaded the MySQL CSV file and tried to open it, nothing appeared to happen. Most likely, the CSV dialog opened on the write doc, but I had forgotten it. I opened calc and tried to open the downloaded file directly from the download folder, and was promptly informed that I had a read-only document in use somewhere else, as I described. I opened as a read-only and tried to save it as an odf with a new name, and that's when LO got into a loop that I couldn't get out of until I restarted my computer ...and even then, LO thought the file was in use and made me tell it to proceed anyway. I share this not in the expectation that I will Gain Satisfaction, but because (1) the non-appearance on top when a CSV file is ready for parsing is a real and replicable bug, at least on my machine, and (2) the death spiral of write protection seemed to me to be something others had experienced, and I could help shed light. I am committed to LO, and support it whenever I can, and have most of my nonprofit clients using it (because they shouldn't waste money on Weird and Excel) and so I took time to record the bug, not because I think the issue is LO's "fault" but because I want LO to get better. Here are the steps to reproduce the buried query "bug": 1. Open an LO app. I'll open write. 2. "Bury" it -- move another window on top of it. 3. Download a CSV file with your browser. I'm getting a MySQL CSV file with the latest Chrome. 4. Open the CSV by clicking it on the browser. Chrome says "opening" but otherwise no apparent change on the desktop. 5. Unbury the open LO instance and Voila! There's the Text Import form. I can get the same result by opening a CSV form from a file manager. Clients find it counter-intuitive that an imported CSV's import dialog would appear, as in this example, on their (buried) word processor. I train them to open calc and have it on top, but they forget. It would be better if the behavior conformed to their expectation that an action would bring the appropriate app to the foreground.
(In reply to Michael Potts from comment #2) > When one downloads a CSV file from a MySQL host via browser, it triggers an > LO intake form that seeks to know the delimiter and other csv parsing info. So here we have essential information that was missing from your initial report. > Here's a constant bug on my Win7 system that I have also experience on my > Win10 system: if LO is already running -- any module -- the intake form > appears on top of the latest instance of LO running, but NOT on top of > everything running. And here's the second piece of important information - the CSV import dialog is not displayed in focus over the top of all the other windows present in that workspace. > Back to this particular bug: I had been editing an LO document with write, > but had closed it. Because of the way I opened it (from a blank LO write > document) the blank LO write doc was still alive, but buried beneath other > apps. When I downloaded the MySQL CSV file and tried to open it, nothing > appeared to happen. Most likely, the CSV dialog opened on the write doc, but > I had forgotten it. I opened calc and tried to open the downloaded file > directly from the download folder, and was promptly informed that I had a > read-only document in use somewhere else, as I described. I opened as a > read-only and tried to save it as an odf with a new name, and that's when LO > got into a loop that I couldn't get out of until I restarted my computer > ...and even then, LO thought the file was in use and made me tell it to > proceed anyway. > I share this not in the expectation that I will Gain Satisfaction, but > because (1) the non-appearance on top when a CSV file is ready for parsing > is a real and replicable bug, at least on my machine, and (2) the death > spiral of write protection seemed to me to be something others had > experienced, and I could help shed light. I am committed to LO, and support > it whenever I can, and have most of my nonprofit clients using it (because > they shouldn't waste money on Weird and Excel) and so I took time to record > the bug, not because I think the issue is LO's "fault" but because I want LO > to get better. Thank you for the detailed instructions. The non-appearance of the CSV import dialog is a known bug.
Or rather the unfocussed display of the CSV import window is a known bug...now to find it and mark this as duplicate.
*** This bug has been marked as a duplicate of bug 32935 ***
Note that a fix has been entered into the master source code repository very recently (2 days ago). It has been tested and reported as working in a current master build, so a daily build version should now include that fix. Eventually, this will filter down into one of the production release builds, and is slated to appear in LibreOffice 6.1