Cannot edit freetext annotation in large zoom levels

WebViewer Version: 10.9.0

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

Please give a brief summary of your issue:
Starting from a certain zoom level, it’s sometimes not possible to edit a free text annotation.

Please describe your issue and provide steps to reproduce it:
Normally, when you create a free text annotation, leave the editor and double click it, you can edit the text inside.

In our application, this issue occured randomly once the zoom level was over 168%. I also found a way to get this consistently in the demo:

  1. Have a zoom level of 100% and scroll to the second page
  2. make a free text annotation and insert some text
  3. scroll to the third page
  4. zoom in a lot (for example: 1675%)
  5. scroll back to the second page text annotation
  6. double click the text annotation
    After these step the text annotation is not editable until you zoom in or out.

In our application, we also had an issue where we could no longer create text annotations in this state until we zoomed in or out (but we found a workaround for this one with some try-catch).

In our development environment we can see an error thrown by webviewer-core.min.js

Expected behaviour:
The text annotation is editable no matter the zoom level or how you get there.

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

Hello Jonas,

I was able to reproduce this issue on our Showcase. Can you reproduce this consistently in your application on a lower zoom level such as below 500%? Are you able to get that error to appear in our demo as well?

Hello Darian,

This is not consistent in our application and only happens sometimes. From our testing, it starts to happen once you reach 168% and it can happen after zooming in or out but also by loading the page. During our testing, we had it happen multiple times in a row while reloading, but also times where we couldn’t recreate it even after reloading the page for 5 minutes straight.

The scenario I described is the only way I found to get it consistently.

When the issue occurs, it’s only that page that doesn’t allow editing. The annotations on other pages are editable.

I couln’t get the error to appear in the demo, I’m guessing either it’s not being thrown or error logging might be disabled?

Hello Jonas,

Thank you for the response.

We were able to reproduce this issue on the Showcase. However, we would like to make sure it’s the same issue in your application. Could you provide a video of the issue in your environment. Would it be possible to create a sample project to reproduce the issue?

Hello Darian,

I created a video that showcases the issue with my console open. You will also see some network errors in there, those are irrelevant.

As I said, it’s not consistent and you’ll see me reload a few times before it happens. When it does, I can no longer edit the text annotations. For some, the text even disappears (But I’m guessing that might be an aftereffect from not being able to open the annotation and our code clearing it).

The forum has a 4MB limit so I’ll send along a wetransfer link: WeTransfer - Send Large Files & Share Photos Online - Up to 2GB Free

Our project is rather large so I’m not sure I can provide a sample project.

Hello Jonas,

I have reviewed the video, but I am not quite sure the issue on the Showcase is the same. I notice many uncaught errors in your console and it looks like you are able to focus (click and get the blinking line) on the annotations.

Hello Darian,

If you’re talking about the errors that pop up for a couple seconds when everything was working fine, those are webviewer errors “No matching annotation in appearance document” (for which I can’t find any explanation).

If you’re talking about the errors when the problem ensues, these originate from the webviewer-core.min.js so I’m not sure what we could be doing wrong.

The blinking line you see is our own custom “caret” that is always visible, wether the user is editing an annotation or just clicking around on the actual pdf text. We also edited the editor css and gave it a purple border when it’s open. If you see the default blue border with the blue dots, that’s just an annotation being “selected”.

The video is recorded previously showcased how our users are experiencing the error. I made another recording using the steps I wrote in my post in both the Pdftron showcase and our project. As you can see there, the annotation is not entering edit mode until i zoom out.

Hello Jonas,

Thank you for the explanation.

I have submitted a report to the product team about this based on your reproduction steps for the Showcase.

Best Regards,
Darian