Navigating to a page in a pdf in web viewer

A Web Viewer shows a pdf. The URL is dynamically generated and has the page number as a parameter:
i.e.
‘file:///Users/user/Desktop/file.pdf#page3’.

The page change is triggered by a script ( see attached) through a button.

The odd thing is that when changing the page number to 6, a click on button the path field changes and web viewer sais 'Loading “file:///Users/user/Desktop/file.pdf#page=6” but does not switch to ne new page.
Only when I click the button a second time, it shows the new page.

Commit and Refresh Window don’t change this.

FMPA 18.0.3 on MacOS 10.14.6. No other pdf viewer than Preview installed.

Any ideas?17

Seems that WV doesn’t reset properly after the first call took place. A had a similar issue where an animated gif (Base64) didn’t load at first enter. Any *“Reload WV” had no effect. I then built a routine by “going blank” and back. In this case, David - CamelCase figured out that fiddling with the ‘HideObject’ can prompt a reload.
For testing and to narrow this down:
For your WV, set a Hide-condition When $$ShowWebviewer = 1

In your script, ahead of ‘Set Web Viewer’, first

# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #

purpose: WV_force_rendering

description:

dependencies:

used in Layout/Script:

comments: set WV-Object with Option ‘Hide When’: $$ShowWebViewer =1

Author: EfficientBizz GmbH - Benjamin Fehr

# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #

// #
// Freeze Window

Set Variable [ $$ShowWebviewer ; Value: 1 ]
Pause/Resume Script [ Duration (seconds): .2 ]
Set Variable [ $$ShowWebviewer ; Value: 2 ]
Refresh Window []

2 Likes

Thank you, @EfficientBizz.

Unfortunately, the trick doesn’t work.

I found out that the ‘Set WebViewer’ step updates the WV’s content immediately when called in a single step script. While calling it in a multi-step script gets it stuck in ‘Loading’.
Attached is a file for testing. Put a multi-page pdf in the ‘Documents’ folder, set the correct file path in field ‘FilePath’.

Account is ‘admin’, no pw.WebViewer Issue.fmp12 (172 KB)

A window mode change preview to browse sometimes refreshes too…

1 Like

Sometimes. Mostly not reliably, but worth a try.
Try also the „FM Voodoo-Toolbox“:

  • commit
  • Pause [ 0,5 seconds]
  • Refresh
    plus the dead chicken you burry in your backyard :wink:
2 Likes

Hello Torsten,

A couple other ideas that I might try if I needed to nudge a WebViewer as you have described:

1) Add a changing dummy query string to the URL:

For instance, instead of:

file:///Users/user/Desktop/file.pdf#page3

Use something like:

file:///Users/user/Desktop/file.pdf?d=1234567#page3

And then, any time that I need to update the hash on the URL, I would also supply a different value for the “dummy” query string parameter of d.

(When I used to do the above, I would just set my dummy var to the result of the
Get(CurrentTimeUTCMilliseconds) function.)

2) Another variation which I never tried, would be to change the base URL by applying some URL-encoding:

So, for instance, I might try a URL such as:

file:///Users/user/%44esktop/file.pdf#page3

I have not tried this particular technique of applying URL-encoding – it’s just something that occurred to me right now as another variation to experiment with.

In both cases, the idea is to trick the WebViewer into thinking that the URL has significantly changed, and therefore encourage it to performa a full update.

I hope that maybe one of these might help.

Kind regards,

-steve

2 Likes

p.s. I just now noticed you posted a demo file to illustrate – I had missed that. I will download and see if the above suggestions work.

Edit: Ah! The sample file does not include a PDF. That was what stopped me from testing the above ideas earlier before posting – I could not find a PDF with anchor tags embedded that would allow me to reproduce the symptoms. Still – maybe the ideas will be of help. I hope so!

4 Likes

It works with any more-than-one page pdf. You may take one of these:
https://www.easa.europa.eu/regulations

Thank you Torsten.

I did my best to reproduce.

Results:

  1. Chrome browser faithfully navigates to the desired page specified by the #anchor.

  2. Safari browser never navigates to the desired page specified by the #anchor.

  3. FMPA v.18 WebViewer never navigates to the desired page specified by the #anchor.

#3 above is true regardless of which of the two buttons (that you provided) I use, and regardless of how many times in sequence I try the buttons. My own attempts to vary your approach resulted in the same, i.e. never navigating to the desired page.

In short, provided I have understood everything correctly, I am observing different behavior than you. It seems that your system is a little better than I what I experience in that, albeit with an additional click, you are able to perform the desired navigation, whereas this is not true on my system.

I am running an older version of MacOS: 10.13.2

I am running what appears to be the current version of FMPA: 18.03.317

Apologies that I could not help to shed any light on this, but I hope this input may still be of some use.

Sincerely,

-steve

I had concluded that the PDF required page anchors for this technique to work, based on how nothing I tried in the WebViewer had worked. I see now why you assert that it works with any PDF: With every PDF I tried in Chrome, the navigation worked fine. Thank you for the clarification on this part.

1 Like

Finally I got that fixed with a modified recipe from @EfficientBizz’ voodoo cookbook.

It goes like this:

  • Set Web Viewer [ your parameters ]
  • Pause/Resume Script [ 0.5s ]
  • Set Web Viewer [ Reload ]
1 Like

@Torsten may I suggest you update the title of this topic to something that evokes pdf page navigation (or anything a bit more specific) in the web viewer. I trust your judgment for the best title, I’m also open to the title staying as is.