https://bugs.documentfoundation.org/show_bug.cgi?id=115316
Michael Potts <mich...@casparinstitute.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |UNCONFIRMED
Ever confirmed|1 |0
--- Comment #2 from Michael Potts <mich...@casparinstitute.org> ---
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.
--
You are receiving this mail because:
You are the assignee for the bug._______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
