https://bugs.documentfoundation.org/show_bug.cgi?id=148407
--- Comment #11 from Telesto <tele...@surfxs.nl> --- (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 :-) -- You are receiving this mail because: You are the assignee for the bug.
