Bug 148407 - Need ability to cancel an ongoing paste action
Summary: Need ability to cancel an ongoing paste action
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.4.0.0 alpha0+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: perf
Depends on:
Blocks: File-Progress-Bar
  Show dependency treegraph
 
Reported: 2022-04-05 20:37 UTC by Eyal Rozenberg
Modified: 2022-04-11 22:01 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eyal Rozenberg 2022-04-05 20:37:56 UTC
Sometimes, pasting content into an LO Writer document can take a lot of time. Even when this is not due to a bug - it might simply be a huge web page with lots of scripts, or what not.

Anyway, while this pasting is going on, you can't perform other actions, especially not with other documents - like saving or closing them.

It should be possible for a user to change their minds after having started a paste - and to cancel the paste by pressing something like Escape or Ctrl+C. That should either cancel the paste immediately, or open up a dialog asking for cancellation confirmation.
Comment 1 Telesto 2022-04-06 09:05:46 UTC
Closely related to bug 148408
Comment 2 Heiko Tietze 2022-04-07 06:50:58 UTC
What use case would you cover with cancel? You changed your mind, long-processing makes text irrelevant, you drink too much coffee since the operation takes literally minutes (the whole page from the referenced bug is pasted in ~10s here)?

Rather than aborting the operation we should speed-up the paste procedure. And the same cancel mechanism would be required for open or save (IIRC we discussed this before but cannot find a ticket).

My take: DUP 148408

Michael, what do you think?
Comment 3 Eyal Rozenberg 2022-04-07 07:11:11 UTC
(In reply to Heiko Tietze from comment #2)
> What use case would you cover with cancel? You changed your mind,

That's it.

> long-processing makes text irrelevant, you drink too much coffee since the
> operation takes literally minutes (the whole page from the referenced bug is
> pasted in ~10s here)?

10s is already enough to let me change my mind. But - that's a 20-line piece of a webpage with a few small images. Now suppose I pasted something that's 100x larger, by mistake. Am I supposed to wait 1000 seconds ? And if you sped it up by 10x - to wait 100 seconds? No.

> Rather than aborting the operation we should speed-up the paste procedure.

That would not solve the problem. LO still would needs this for large pasted content.

> And the same cancel mechanism would be required for open or save (IIRC we
> discussed this before but cannot find a ticket).

Not sure about "Save", but for open - yes, it should definitely be possible to cancel an Open.
Comment 4 Telesto 2022-04-07 08:38:07 UTC
Well I surely have had few freezes of up to 120 seconds.. Sometimes I even kill soffice.bin.. And in general I avoid webpastes to LibreOfffice (because of possible freezes)

In cases of high bandwidth and proper internet connection it should freeze at all (it does). And in cases where of low bandwidth (and say large images) or bad internet connection there are merits for 'abort'

I dislike a UI button, but simply press 'ESC' to kill the paste (simply paste keep what's already pasted) 

-----
Few other remarks..  
However I speculate that failure  of downloading the image (there is apparently a time-out at some point), well end up link to the image instead of embedding the image.. See bug 148027. And that stupid link gets accessed on every file-open (and if the linked domain being slow, it entails slow file opening.. waiting a minute for 50 kb file to open) because some 7 megabit file on some webserver at the other side of the world with small upload  

And this is yet again problematic, because there was no intention to have 'link to images' but intended embedded images (when I opt for copy/paste). Else you might lose images (link died) and well it makes files slow to open

---

In general some could argue that a warning dialog would be appropriate (infobar?). The file contains linked files to the internet, do you want to download

----
And the lovely is that those image which do refuse to be downloaded are mostly stuff of unimportance.. Facebook, Whatsapp buttons
Comment 5 Eyal Rozenberg 2022-04-07 18:52:44 UTC
(In reply to Telesto from comment #4)
> I dislike a UI button, but simply press 'ESC' to kill the paste (simply
> paste keep what's already pasted) 

That is fine with me. 

But - I remember that when we open a docx there someplace where we get a progress bar. Perhaps if there was a progress bar for pasting (under certain circumstances, e.g. shown after at least X seconds have passed etc.) then the text on the scroll bar could also say "(Esc to abort)" or something.


> And this is yet again problematic, because there was no intention to have
> 'link to images' but intended embedded images (when I opt for copy/paste).
> Else you might lose images (link died) and well it makes files slow to open
>
> In general some could argue that a warning dialog would be appropriate
> (infobar?). The file contains linked files to the internet, do you want to
> download

That sounds like a separate bug. Would you like to file it, or shall I?

I have some stuff to say about these points, but I would like to say it on the separate bug rather than here.
Comment 6 Heiko Tietze 2022-04-08 07:10:14 UTC
From UX POV, feedback is important (change the cursor to hour glass, show a progress bar) as well as control over the processing (move operations to the background, allow to abort). This is a quite generic reply and it always needs balancing with development effort.

In respect to the interaction I think escape might be pressed unintentionally. We show a progress bar on long operations and a "x" button could be easily added there.

Very similar request in bug 49701
Comment 7 Telesto 2022-04-09 13:49:44 UTC
(In reply to Eyal Rozenberg from comment #5)
> That sounds like a separate bug. Would you like to file it, or shall I?
> 
> I have some stuff to say about these points, but I would like to say it on
> the separate bug rather than here.

Please go ahead :-)
Comment 8 Telesto 2022-04-09 13:57:46 UTC
(In reply to Heiko Tietze from comment #6)
> In respect to the interaction I think escape might be pressed
> unintentionally.

I'm not totally seeing the problem. Writer nearly freezes on paste. So any other interaction is as good as impossible. 

The whole UI gets pretty unresponsive on a webpaste. Obviously not saying it should be necessary ESC (but well sure what the other options could be)
Comment 9 Eyal Rozenberg 2022-04-09 14:30:06 UTC
(In reply to Telesto from comment #8)
> I'm not totally seeing the problem. Writer nearly freezes on paste. So any
> other interaction is as good as impossible. 

Not true. I can switch to another document, place the cursor, type... while the pasting is going on.
Comment 10 Michael Stahl (allotropia) 2022-04-11 14:08:51 UTC
depending on the content that's being pasted, i see are 3 problems:

* pasting the content takes a long time
  - actually this seems rather unlikely to me
  - theoretically it might be possible to cancel but likely not
    worth the effort, and it would need a specific test case first

* it's complicated to layout
  - in this case, there isn't any way to "cancel" because
    the layouting starts after the content is fully pasted.
  - in certain places it is already checked if an input event
    is being received which interrupts the layouting; this
    is already a kind of "cancel" although if the document view
    displays content that hasn't finished layouting it doesn't help
    (the main case where it helps is if you interact with a
    different LO document than the one that's layouting)

* it contains lots of hyperlinked images
  - i think the images are loaded asynchronously, but if the layout
    depends on the size of an image, it will probably block at
    that point so it's only theoretically async...
  - possibly this could be changed to be more incremental although
    that's a bit risky...
  - also some sort of cache could perhaps help - i think there has
    never been any caching at the HTTP level so it could download
    e.g. the same list bullet image multiple times
Comment 11 Telesto 2022-04-11 15:46:13 UTC
(In reply to Michael Stahl (allotropia) from comment #10)
> * pasting the content takes a long time
>   - actually this seems rather unlikely to me
>   - theoretically it might be possible to cancel but likely not
>     worth the effort, and it would need a specific test case first

If you ask me, it's not the pasting in general, it's really specific about image handling when pasting from the web. Borrowing from bug 148027

Steps to Reproduce:
1. Go to https://tree.taiga.io/project/rrbd-weststadtputz-2022/wiki/home with a browser
2. Select "Das Weststadtputz-Wiki" until  "Wer steht dahinter?"
3. CTRL+C
4. CTRL+V in Writer 
5. Instead of embedding the image (initially expected_, Image link being created point somewhere to the web. [Note: you might need to throttle bandwidth to see this.]

I assume there is some sort of time out or another reason the image download is failing (to big?). And instead of embedding the image will inserted as a link. 

Now LibreOffice attempt on every file opening the download the file.. or in other cases of interaction :-( 

----------------

I'm unsure how LibreOffice handles image downloading.. So a webpaste contains 40 images.. Does it download all one by one (slow) or the opposite, all in parallel; hammering the server, which might start to throttle? 

----------------
Creating Image links is one thing, knowing which image are linked image is something else (Navigator?). And the ability have some button fetch all linked images and embed them would be also nice :-)

----------------
Visa versa is it practical to now which images are failing to be downloaded. 

> * it's complicated to layout
>   - in this case, there isn't any way to "cancel" because
>     the layouting starts after the content is fully pasted.
>   - in certain places it is already checked if an input event
>     is being received which interrupts the layouting; this
>     is already a kind of "cancel" although if the document view
>     displays content that hasn't finished layouting it doesn't help
>     (the main case where it helps is if you interact with a
>     different LO document than the one that's layouting)

Probably what I'm experiencing at step 5 

> * it contains lots of hyperlinked images
>   - also some sort of cache could perhaps help - i think there has
>     never been any caching at the HTTP level so it could download
>     e.g. the same list bullet image multiple times

This would be lovely :-)
Comment 12 Eyal Rozenberg 2022-04-11 22:01:21 UTC
(In reply to Michael Stahl (allotropia) from comment #10)
> * pasting the content takes a long time
>   - actually this seems rather unlikely to me

Opening a large .docx file takes a lot of time (for some definition of "a lot"); so why would pasting from MS-Word, or from a browser viewing an MS-Word-generated HTML file, not take a lot of time?

>   - theoretically it might be possible to cancel but likely not
>     worth the effort, and it would need a specific test case first

It is absolutely worth the effort. Take any testcase, run it on a weaker computer and make the document N copies of itself, and you have testcase which takes a long enough time.

> * it's complicated to layout
>   - in this case, there isn't any way to "cancel" because
>     the layouting starts after the content is fully pasted.

I'm not knowledgeable enough to doubt this, but it seems strange to me that LO freezes until it layouts a huge document, without showing the user anything and accepting user input. If that's the case, that needs to change, which would also allow for supporting cancellation of the paste.

>   - in certain places it is already checked if an input event
>     is being received which interrupts the layouting; this
>     is already a kind of "cancel" although if the document view
>     displays content that hasn't finished layouting it doesn't help
>     (the main case where it helps is if you interact with a
>     different LO document than the one that's layouting)

so, it's not a "kind of cancel".

> 
> * it contains lots of hyperlinked images
>   - i think the images are loaded asynchronously, but if the layout
>     depends on the size of an image, it will probably block at
>     that point so it's only theoretically async...

Well, that would be a bug in itself. An assumption should be made about the size, layout should proceed accordingly, and asynchronously the layout should be updated with the actual size and content.

>   - possibly this could be changed to be more incremental although
>     that's a bit risky...

How so? I mean, other than how any work making something less-blocking is slightly dangerous.

>   - also some sort of cache could perhaps help - i think there has
>     never been any caching at the HTTP level so it could download
>     e.g. the same list bullet image multiple times

Perhaps, but that's a separate issue. The user needs to be able to cancel a paste.


By the way - if the "cancel" only affects the not-yet-processed / not-yet-layed-out parts - that would be good enough, since one could then use Undo to remove everything that was actually pasted.