Preview not following quick switch between items

[mjthoraval]

Steps to follow:

1. Select an item in the library
2. With the keyboard arrows, go rapidly up to the item above, and then directly down to the first item selected.
3. The preview moves to the item up, but does not come back to the first item.

Screen recording.

[windingwind]

Does this still happens in v0.3.2?

[mjthoraval]

Still happening in v0.3.4.

[windingwind]

Please try v0.3.6

[mjthoraval]

Still have the problem in v0.3.6.
It seems to be even worse, keeping the wrong preview even when other types of fast switching between items.
Let me know how I can help debug it.

Here is an error message I get:
[JavaScript Error: "TypeError: iframe is null" {file: "chrome://pdfpreview/content/scripts/index.js" line: 407}]

In this latest version 0.3.6, it seems that the preview is getting very slow.
After doing fast switching between items from the keyboard, I am getting Zotero to become unresponsive. I need to kill Zotero to recover.

Just by switching quickly between items, the RAM usage goes up to 2.6 Go and does not go down anymore. The processor usage goes up to 33% and also stays there constantly.

I have tried moving back to Release 0.2.10. I am also getting the same CPU and RAM usage, and finally Zotero getting unresponsive. So either I had not pushed testing that far before, or something has changed in the underlying code used by the plugin?

I am using Zotero 6.0.16-beta.4+410ebc288 on Windows 10.

I have now switched to Zotero 6.0.15 and PDF Preview v0.3.6 for testing. I am getting similar behaviour (it seems to take more time to trigger though), with this error:
[JavaScript Error: "TypeError: iframe is null" {file: "chrome://pdfpreview/content/scripts/index.js" line: 396}] [JavaScript Error: "TypeError: iframe.contentWindow.cachedData is undefined" {file: "chrome://pdfpreview/content/scripts/index.js" line: 396}]

To be more precise, I am using the Preview in Info Tab, with "Preview First 10 Pages".
To trigger the problem, keep pressing the down arrow for 50 times with items that have a PDF file attached.

[windingwind]

@mjthoraval How about v0.3.7?

We discussed the memory leak issue: #5 and added the pdfDocument.destroy() following the pdf.js official suggestion. However, it seems to still have some part of the file or rendering buffers not freed. I've tried and seem like the only way is to remove and create the iframe after previewing several items, which is 10 in v0.3.7.

I've confirmed that the memory usage will be about 1.5G if you quickly switch between items, and go down to 0.5-0.7G after stopping the operation.

[mjthoraval]

Thank you very much. I still went up to 2G of RAM in some cases, but it never gets Zotero unresponsive anymore.
I am still getting an error message, but I don't know what it means:
[JavaScript Error: "TypeError: iframe is null" {file: "chrome://pdfpreview/content/scripts/index.js" line: 408}]

The original problem reported in the first post of the thread is still there though.
I can reproduce also on Ubuntu 20.04 and MacOS Monterey Version 12.6, with PDF Preview v0.3.7.
It is a small problem, that does not come out too often, so it is not urgent to fix.

[windingwind]

I still went up to 2G of RAM in some cases

The garbage collection cannot be called manually, and Zotero will not do the GC actively when there are many tasks still running. So it is reasonable to go over 2G or more if you keep switching very fast.

My test is based on the newly started Zotero. Background services like syncing and refreshing RSS also may cause more RAM usage. If it is about 1GB or less after you stop operations for a while and the CPU usage goes down to 0%, then there should be no memory leakage now.

but it never gets Zotero unresponsive anymore

Glad to hear that.

The original problem reported in the first post of the thread is still there though.

Yes, I haven't taken the time to handle that yet. Memory leakage is much more severe and urgent.

[JavaScript Error: "TypeError: iframe is null" {file: "chrome://pdfpreview/content/scripts/index.js" line: 408}]

Does this appears only once (on startup), or every time the 'no following' happens?

[mjthoraval]

I have tracked down the JavaScript Error. It appears only once when the BBT Citation Keys are loaded.

[windingwind]

That's OK because the iframe is reloaded after BBT loading. During this stage, it is possible to meet this error. Does not affect the preview.