Bug 49701 - Provide UI button to abort loading of a file
Summary: Provide UI button to abort loading of a file
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords: needsDevEval, topicUI
: 88102 (view as bug list)
Depends on:
Blocks: File-Progress-Bar cancel-long-operations
  Show dependency treegraph
 
Reported: 2012-05-09 12:12 UTC by Sergey
Modified: 2024-04-25 02:41 UTC (History)
12 users (show)

See Also:
Crash report or crash signature:


Attachments
UI blocked while XLS opening (47.24 KB, image/png)
2012-05-09 12:24 UTC, Sergey
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sergey 2012-05-09 12:12:35 UTC
Problem description: 
Some files take significant time to open. These could be large files or imports of external formats.

Current behavior:
Currently there is no UI to cancel such opening process. The only way is to kill libreoffice via operating system.

Expected behavior:
Have a "Cancel" button in file open progress screen which will terminate load.

Platform (if different from the browser): 
              
Browser: Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.19 (KHTML, like Gecko) Ubuntu/10.04 Chromium/18.0.1025.151 Chrome/18.0.1025.151 Safari/535.19
Comment 1 Sergey 2012-05-09 12:23:43 UTC
Also, opening a file should never block UI. See attachment.
Comment 2 Sergey 2012-05-09 12:24:11 UTC
Created attachment 61303 [details]
UI blocked while XLS opening
Comment 3 Roman Eisele 2012-05-24 01:21:59 UTC
This is a UI issue, therefore changed the Component field accordingly.

This is an enhancement request, therefore changed the Importance field accordingly.

Set Status to NEW, because I can confirm that there is no 'Cancel' button for file opening ;-) Also, pressing ESC or Cmd+. (Cmd+. was the old standard cancel shortcut on MacOS) does not stop the fileopen process.

So IMHO this is a reasonable enhancement request; this enhancement would be very useful with large files, esp. with some .doc and .docx file which take very long to open ... (see e.g. bug 39179).
Comment 4 tommy27 2014-12-13 09:24:31 UTC
I agree that an "abort" loading of a file would be an useful enhancement.
issue is inherited from OOo.
Comment 5 Thomas Lendo 2017-06-16 09:34:28 UTC
Where could such an abortion button be placed when there is no file dialog open? Only pressing ESC would make sense imho.

Adding keyword needsUXeval.
Comment 6 Heiko Tietze 2017-06-16 09:40:41 UTC
(In reply to Thomas Lendo from comment #5)
> Where could such an abortion button be placed when there is no file dialog
> open? Only pressing ESC would make sense imho.

Lengthy operations (>500ms) have to go into background but feedback is still needed. That's typically done with a progress bar in the statusbar (or the address bar in case of Internet browsers) where the cancel button would fit well. While UX can easily demand such a feature it is likely a challenge for the developers.

Escape is not a good idea as it could be pressed accidentally.
Comment 7 Yousuf Philips (jay) (retired) 2017-06-16 13:09:29 UTC
I've suggested the cancel button and Esc key in bug 88102. Cancel button is good for visual users and Esc is good for accessible users.

Cor, Stuart: What's your take?

Maxim, Samuel: Can you give your input from a dev's perspective what is possible.
Comment 8 V Stuart Foote 2017-06-16 13:34:42 UTC
*** Bug 88102 has been marked as a duplicate of this bug. ***
Comment 9 V Stuart Foote 2017-06-16 13:37:17 UTC
A toolbar button widget with assigned shortcut would probably be best UX, <Esc> can be a bit random about what it is applying to--not sure we can assure opening of document is the actual target.
Comment 10 Yousuf Philips (jay) (retired) 2017-06-16 17:04:40 UTC
(In reply to V Stuart Foote from comment #9)
> A toolbar button widget with assigned shortcut would probably be best UX,

Not sure a shortcut key would be something possible for users to know or even discover, which is why <Esc> would be a good candidate.

> <Esc> can be a bit random about what it is applying to--not sure we can
> assure opening of document is the actual target.

<Esc> is quite common to cancel the last action, like closing an open a dialog, exiting insert mode when drawing a shape, closing an open split/group button, etc.
Comment 11 tommy27 2017-06-17 06:25:20 UTC
what about putting a message in the loading dialog progess bar saying: "LibO is loading the file. press <Esc> to abort"

IMHO the Esc key is unlikely to be accidentely pressed since it's in the left upper corner of each keyboard.
Comment 12 Heiko Tietze 2017-06-17 07:37:36 UTC
By the way, what happens meanwhile when the loading takes ages? Are you allowed to continue with the recent document? If not showing a confirmation box or special notification area with progress bar and cancel button is also an option.
Comment 13 Cor Nouws 2017-06-19 13:06:43 UTC
<ESC> is the key to use, IMO.

Mind: what to do, or show to the user, when loading hangs? Is 'About loading' expected to load that too?
Comment 14 Cor Nouws 2017-06-19 13:07:19 UTC
(In reply to Cor Nouws from comment #13)

> Mind: what to do, or show to the user, when loading hangs? Is 'About
> loading' expected to load that too?
                    to stop that too?
Comment 15 Yousuf Philips (jay) (retired) 2017-06-20 22:18:09 UTC
(In reply to Heiko Tietze from comment #12)
> By the way, what happens meanwhile when the loading takes ages? Are you
> allowed to continue with the recent document?

To my knowledge it locks up LO as a whole while the document is loading.

> If not showing a confirmation
> box or special notification area with progress bar and cancel button is also
> an option.

Dont really get what a confirmation box would provide. What would you want to put in a special notification area?
Comment 16 Heiko Tietze 2017-06-21 07:05:07 UTC
(In reply to Yousuf Philips (jay) from comment #15)
> (In reply to Heiko Tietze from comment #12)
> > By the way, what happens meanwhile when the loading takes ages? Are you
> > allowed to continue with the recent document?
> 
> To my knowledge it locks up LO as a whole while the document is loading.
> 
> > If not showing a confirmation
> > box or special notification area with progress bar and cancel button is also
> > an option.
> 
> Dont really get what a confirmation box would provide. What would you want
> to put in a special notification area?

The status bar is not really a prominent area. Having the progress bar with a cancel button in the notification area or in a dialog provides more control as a side effect. The question what LibO is doing meanwhile was asked to think about a threaded process so the user doesnt need to wait. But she has nothing to do on the other hand.
Comment 17 Yousuf Philips (jay) (retired) 2017-06-21 13:30:54 UTC
(In reply to Heiko Tietze from comment #16)
> The status bar is not really a prominent area. Having the progress bar with
> a cancel button in the notification area or in a dialog provides more
> control as a side effect.

Yes the status bar isnt a prominent area, as the loading process of a document isnt intended to be something prominent, as it should only take a few seconds in the best case scenario. It is only when the loading process takes a long time is it important for the user to even care about it.

So to me the infobar or a dialog is would be bad UX, as it brings to much attention to this process, which should be something that users should never think about. Imagine opening the file open dialog, selecting a document to open, and then a dialog flicker infront of you during the loading process and then you see your document after 1 second. Also i tested loading a document and it only draws the UI (menu bar, toolbars, sidebar, etc) after the document is fully loaded, so not sure that we could provide an infobar in that scenario.

> The question what LibO is doing meanwhile was
> asked to think about a threaded process so the user doesnt need to wait. But
> she has nothing to do on the other hand.

Yes ideally you should be able to work on an already open document, while another document is being loaded, but i dont think LO has threaded processes yet. Firefox just got it a few days ago. :D
Comment 18 V Stuart Foote 2017-06-21 15:17:50 UTC
The UI already incorporates a "useful" location.  As the document is parsed for opening from the Start Center, or from system file manager--as the document frame opens there is a load progress bar rendered on the status bar labeled "Loading document..."

Normally it flashes up so quickly, you won't notice it. I had to dummy up a 800 page document to show it long enough during normal loads.

Question would be if that status/progress bar does "hang", or could be made to do so, and if we can extend it with a button widget to abort the loading of a hung document. It is already in the best location.

=-ref-=
http://opengrok.libreoffice.org/xref/core/vcl/source/window/status.cxx
http://opengrok.libreoffice.org/xref/core/framework/source/helper/statusindicatorfactory.cxx
Comment 19 Yousuf Philips (jay) (retired) 2017-06-23 01:42:04 UTC
(In reply to V Stuart Foote from comment #18)
> The UI already incorporates a "useful" location.  As the document is parsed
> for opening from the Start Center, or from system file manager--as the
> document frame opens there is a load progress bar rendered on the status bar
> labeled "Loading document..."

The label isnt consistent across apps (bug 108706) and sometimes doesnt show (bug 108707).

> Normally it flashes up so quickly, you won't notice it. I had to dummy up a
> 800 page document to show it long enough during normal loads.

Yes most users wont notice the progress bar unless it is a large/complex file or if the loading process has stalled.

> Question would be if that status/progress bar does "hang", or could be made
> to do so, and if we can extend it with a button widget to abort the loading
> of a hung document. It is already in the best location.

Yep the devs have to give their input on whether it is even possible to exit out of the import routine with the proposed 'cancel' button.

Meeks, Thorsten, Samuel, Maxim: Any thoughts?