Keeping layout between tabs doesnt work

WebViewer Version: 8.4.1

Do you have an issue with a specific file(s)? No
Can you reproduce using one of our samples or online demos? Not available
Are you using the WebViewer server? Yes
Does the issue only happen on certain browsers? All browsers
Is your issue related to a front-end framework? No
Is your issue related to annotations? No

Please give a brief summary of your issue:

When loading a new tab (or clicking on a previously opened tab), the “original” Pdftron layout is lost.
For example, if you use
WebViewer({ ...options }, wvElement).then(() => { instance.UI.openElements([ 'menuOverlay', 'leftPanel' ]); });

The leftPanel won’t stay open when navigating to a new Tab or when coming back to a previous tab.
You have to call it explicitly when loading a new document
instance.UI.openElements([ 'leftPanel' ]);

Please describe your issue and provide steps to reproduce it:
(The more descriptive your answer, the faster we are able to help you)

Please provide a link to a minimal sample where the issue is reproducible:

Hello, I’m Ron, an automated tech support bot :robot:

While you wait for one of our customer support representatives to get back to you, please check out some of these documentation pages:


Hello @MichaelL

I’m assuming that by “tab” you mean “browser tab”. let me know if that’s not the case.

WebViewer does not maintain the UI state across different tabs, but this can be easily achieved by using the local storage to control what is open and what is closed (or any other state that is relevant to your business case). In order to do that, you would have to built it on top of WebViewer (with a config file or WebViewer’s constructor callback) or by forking the UI and customizing it (You can read more about this option here:

Hello Felix

Thanks for your reply.

I’m actually talking about the new tab functionality in pdftron webviewer 8.4.1., which allows to open multiple tabs in one pdftron webviewer instance.


Hello @MichaelL

I see. This is actually expected because the panels should close when the document is unloaded (which happens when you switch tabs). That being said, two approaches come to mind:

1 - Open the elements you want when a document is loaded with the following code snippet:

instance.Core.documentViewer.addEventListener('documentLoaded', () => {
  instance.UI.openElements([ 'menuOverlay', 'leftPanel' ]);

2 - Fork the UI and change the elements you want to close when a document is disabled. This is the file that gets called when a document is unloaded: webviewer-ui/onDocumentUnloaded.js at 8.4 · PDFTron/webviewer-ui · GitHub . As you can notice, leftPanel is an entry on the list of elements that get closed.

Hello Diego

As far as 1 goes, this is already being done on our side and what we did before using tabs.
To be honest, it’s a bit rough because the panels (left and notes) are being closed and reopened with an animation in the UI when switching document, be it when loading a new document (no tabs used) or opening a new tab when loading a new doc.

What I dont get though is why is a document unloaded when switching tabs? We use the load : true saveCurrent : true parameters (see PDFTron WebViewer Class: TabManager) to save the state but I’m wondering what it does exactly then? Neither the current page or any parameter is actually being saved?

In any case we will investigate a potential fork as proposed.



Hello @MichaelL

Can you send me the code you use to add those tabs?


let options = {
            extension: extension,
            documentId: uuid,
            filename: filename,
            customHeaders: {
              Authorization: 'Basic keyremoved'
            withCredentials: true,
            load: true, 
            saveCurrent: true, 
          this.wvInstance.UI.TabManager.addTab(environment.renderURL +filename, options);

Hello @MichaelL

I got clarification about those two options there:

  • load: it sets that tab to be the active one. It does not pre-load the document.
  • saveCurrent: save the annotations, scroll, and zoom for the currently loaded tab. The panels’ state is not saved at this point.

We will add this clarification to the documentation. Would you like to add a feature request for saving the panels’ state? If so, anything else you would like WV to save the state of?

Thanks Diego, this is more clear for me.

As for your questions, I think there is a major problem with the way the tabs are being handled.

  • First, there is a discrepancy between opening a new tab programatically when loading a document, and opening a new tab with the user interface. In the first case, you can save the annotations scroll and zoom, in the second case, it is lost.
  • There is also a discrepancy between opening a new tab programatically and using the interface to navigate between existing tabs. In the first case, you save the annotations, scroll, and zoom, in the second case, nothing is being saved. This behaviour is very difficult to apprehend as a user.

Ideally, I think there should be a way to load webviewer so that any tab manipulation (new tab, navigate between tab, load a new doc, …) will have the same behaviour : either save the current status, or don’t.

As for what is being saved, I think there are two possibilities :

  • The panel configuration is the same for all tabs (this is my prefered choice). If a panel or a toolbar was added / modified / opened, it stays the same across all tabs and there are no animations when switching tabs
  • The panel configuration is saved per Tab and the UI is “reloaded” for each tab. This seems counter intuitive to me but I can guess it would be interesting in some use cases.

Also, I think the current tab implementation is deficient : there are a lot of bugs (that I reported here or directly with the support, like with the TabManager API), and it is generally unstable. The webviewer frequently disapears totally when loading a new tab. This is hard to reproduce with a controlled scenario though, it seems pretty “random”. It should be, imho, be marked as experimental / in developement.

In any case, thanks for looking into this and I’ll be glad to help or give more detailled info if needed.


Thanks for the feedback.

I’ve added this to the WebViewer’s backlog.

Hey @MichaelL

Just letting you know that the issue with the state not being saved when you switch tabs using the UI is fixed now and the fix is available on the nightly stable build for 8.4.1. You can find it here:

1 Like

Hello Diego

i’ve tested the latest nightly and the state is not being saved when switching between tabs.
Build: “NS8xNS8yMDIyfDIwNzUyYWFjMg==”

Hello @MichaelL

I apologize if I wasn’t too clear.

What is working right now (and it was not prior to this ticket) is saving state (annotations, zoom level, and scroll position) between tabs if you added the tabs programatically. This was considered a bug and was fixed.

The panels are still not part of the state. This was considered an enhancement and it’s not ready yet.

Yes that is what I understood but these parameters are not being saved when switching tabs.

Lets say I go back to a previous tab B, change the zoom level, switch to tab A again and come back to the tab B, the zoom level won’t be the last one I set.

Hello @MichaelL

Just to make sure I understand, Is this the workflow you are doing:
1 - Add tab A
2 - Add tab B
3 - Go to tab A and set zoom level to 200%
4 - Go to tab B and scroll to page 4
5 - Go back to tab A and the zoom level is not 200%
6 - Go back to tab B and the scroll is not positioned on page 4

I just followed these steps and it seems to be working for me. Am I missing something?

Hello Diego,

I just tried on an empty project to have the easiest example possible on my side and cant accurately reproduce the bug I had.
On our main project, I have no idea what triggers or not the fact that sometimes it doesn’t save a tab zoom level or page, but I can assure you it is happening frequently on the first tab. I can send you a small video / gif of this happening if you want.

Also, the webviewer is very frequently crashing when switching tabs or loading a new tab, and you need to refresh the whole page to start again. It makes testing quite hard tbh.

Hello @MichaelL

I will ask you kindly to start a new thread about WebViewer crashing when using multiple tabs.

Regarding the original topic of this thread: Yeah, a recording of it would help me to notice any step that I might be not doing. Nonetheless, if you can’t reproduce it in a simple WebViewer setup, probably something in the application’s code is interfering with it, and, regarding specifically this interference, there is not much I can do to identify the issue.

Yes it probably boils down to an interference with the application’s code.
I’m conducting further tests to try to pin what exactly is the problem regarding the state not being saved in some case.

I can already say that the documentLoaded event is being sent every time you switch to a tab with the UI and in my case I think it does create some problems.
While I understand it should be fired when opening a new document, I don’t think it should be fired at every tab switch. Maybe there should be a different event when the user switches tab?

Hello @MichaelL

You can use this event: