search

RocketChat / Rocket.Chat

The communications platform that puts data protection first.
https://rocket.chat/
Other
39.95k stars 10.29k forks source link

PDFs are not shown collapsed, makes rooms very slow #15082

Open stleitner opened 5 years ago

stleitner commented 5 years ago

Description:

PDFs are always shown as preview. This makes the app very slow when many PDFs are attached to a room.

Steps to reproduce:

Open room with attached PDFs (in MacOS App and Firefox Browser)

Expected behavior:

All PDFs should be shown collapsed

Actual behavior:

All PDFs are shown as preview, not collapsed. The room does not show the bottommost message, you find yourself somewhere in the middle (this might be the correct position if all PDFs would be collapsed). Sometimes the PDF are shown upsidedown.

Server Setup Information:

Client Setup App

Client Setup Browser

Additional context

The "Auto Load Images" setting is false, "Save Mobile Bandwidth" is false and "Collapse Embedded Media by Default " is true

Workaround in Settings - Layout - Custom CSS:


.attachment-canvas{
    display:none !important;
}
reetp commented 5 years ago

Upside down PDFs are addressed here: https://github.com/RocketChat/Rocket.Chat/issues/15012

You should now be on 1.2.x at least and should really test on latest.

Do you have a reverse proxy and can you confirm your websockets are working OK.

bhdung commented 5 years ago

I have setting layout custom css like you setting . But the problem still on going when reload page the function preview pdf call sometime make crash app desktop. How can i stop call the function pdf preview with pdf file upload

stleitner commented 5 years ago

@reetp The problem is still there with version 1.2.3. All PDF thumbnails/previews are still shown by default. All PDFs files are downloaded in full (some have 20MB or more).

Reverse proxy is configured (https://rocket.chat/docs/installation/manual-installation/ubuntu/snaps/autossl/) Caddyfile:

https://domainname:443 {
  proxy / localhost:3000 {
    websocket
    transparent
  }
}

There are no websocket errors in the browser console.

@bhdung I know, the PDF files are still downloaded when using the workaround. This one hides the loading animation as well:

.attachment-pdf-loading,.attachment-canvas{
    display:none !important;
}
reetp commented 5 years ago

All PDFs files are downloaded in full

That doesn't necessarily make sense. A preview is a preview.

As far as I can see it doesn't load the PDF into the channel - just a snapshot icon and a download URL - it does not have a PDF viewer built into Rocket so it cannot be loading the full PDF.

If you right click the rendered icon and do Save As it will save a download.png and even an A4 PDF one is only 54kb on my test here. That's the only thing that actually gets 'loaded'.

There are no websocket errors in the browser console.

You won't see them just with a quick look. Chromium, Inspect, Network, F5 to refresh look under WS for a websocket, then click the websocket to see if it is OK.

A-Websocket1

A-Websocket2

I think what is happening is when you refresh the channel it is taking a long time to regenerate the preview icon in the channel - it isn't actually downloading the PDF.

I can see that occurring briefly on mine for a larger PDF.

I'm not sure why the preview icon isn't cached then??

What specs are the servers here? Hosted, shared, CPUs, RAM etc??

reetp commented 5 years ago

Possible solutions:

stleitner commented 5 years ago

@reetp websocket looks normal: screenshot_wss

The PDF file downloads are listed in the inspect network listing, when loading the room: screenshot_pdf

The server runs on vSphere with 4 CPU and 6GB RAM

I tried to do a quick test with latest docker image, but RocketChat can't connect to the MongoDB container. I have to test it on monday.

reetp commented 5 years ago

KK - so we have eliminated websockets (often a cause of poor performance)

As to whether the PDF is actually cached into the browser, or it is a rendering issue, I don't know - way above my pay grade. Is the PDF file being downloaded to the browser and an icon generated/rendered then? If so that is really ugly and will be slow with big files, especially if you have a lot of them.

I can see it chiselling away with pdf.worker.min.js

Bit more reading around. This is the library used:

https://github.com/mozilla/pdf.js

https://github.com/mozilla/pdf.js/wiki/Frequently-Asked-Questions#range https://github.com/mozilla/pdf.js/wiki/Frequently-Asked-Questions#optimize

So as far as I can see this is great if you have the odd small PDF, but it's not going to be very clever if you use lots of big ones.

I think this needs addressing by the devs (funny how users always do what you least expect)

Hopefully this will get some attention fairly soon.

The simplest solution will be to disable PDF rendering in the browser and just post a link.

I also think the icon rendering should be server side, not client side.

stleitner commented 5 years ago

Please do not change the uploaded PDF file at all, save an addional thumbnail file.

JPEGs are already manipulated/compressed by Rocket.Chat on upload, if they have rotation information included #11480 and this isn't fixed for one year. This causes a lot of time for administrators to find this problem in the workflow and cause a lot of confusion why images are received with bad quality.

In some usecases (printing or high resolution stuff) the files need to stay big as they are, because they are part of a workflow. Compression should be done at the very end of the workflow, not in the beginning or in the middle.

reetp commented 5 years ago

I'm not changing anything - I'm not a developer - just trying to triage the situation.

Please do not change the uploaded PDF file at all, save an additional thumbnail file.

What? I never said anything about it modifying a file?

I was trying to work out what happened behind the scenes. Please go and read the links so you understand yourself exactly what is going on and what the issue is.

JPEGs are already manipulated/compressed by Rocket.Chat on upload,

I think you should remember that Rocket is a chat system - I'm not sure it was ever designed as a cloud file transfer/storage system - there are other better systems for handing that sort of idea specifically.

We also are in the printing business so I do understand - personally I wouldn't dream of using Rocket as our system for moving files about..... it's not the really right tool for the job IMHO. There are other tools much better suited to the task.

Rocket is fine for say showing someone a quick preview for review etc, but that is its limit, and I think that is about as far as it was intended to be used.

You may find this Issue will get set 'wontfix - do not use for transferring larges files'

stleitner commented 5 years ago

@reetp I‘m very sorry that you understood that I blame you personally responsible for this issue. That was not the case.

„funny how users always do what you least expect“ as you earlier said: There is not the only one workflow for everyone, so a good product/tool is providing multiple options for its users. Especially if a product want to bring multiple departments together. Otherwise users start sending big files by email again or sensible/personal data through external cloud services, for example.

A switch to enable/disable PDF preview serverwide and/or by user would give every administrator the oportunity for the own use case.

bhdung commented 5 years ago

Hi, like in image so many call request to pdf.worker.min.js, like never stop it make crash in brower and blank when using desktop app

Untitled

Make browser crash

Untitled2

My own server running in Centos 7.6, 8 CPUs, 24 Gib Ram, I'm runing 2 instances with RC version 1.3.2 .I dont know how i can stop this or i can fix it, i'm not developer :(.

reetp commented 5 years ago

This is all about the law of unintended consequences. What seemed like a good idea turns out to be a weight around you neck.

My own server running in Centos 7.6, 8 CPUs, 24 Gib Ram, I'm runing 2 instances with RC version 1.3.2 .I dont know how i can stop this or i can fix it, i'm not developer :(.

We already know all this - I have explained about what the problem is. I am not a developer either. Just working out what the issue is.

Currently the only option is to not send lots of PDFs, or work out yourself how to stop it loading pdf.worker.min.js (block it in your proxy?) but then you lose the links I guess......

In the meantime you will have to wait and see what the devs decide to do.

To 'fix' this they may well have to bin the current system and use something else, or at least write an alternative. I'm not sure it is going to get fixed in a hurry.

A switch to enable/disable PDF preview serverwide and/or by user would give every administrator the oportunity for the own use case.

That is one possibility to prevent the PDF preview working - but you would then still want a link, and a preview. So just switching it off is not necessarily the solution as you would want an alternative.

The other way is that there are plenty of self hosted file store solutions out there eg youtransfer, projectsend, Pydio, linshare to name a few.

An integration of one of those with Rocket may be a more sensible idea in the long run.