Users can't sign in 'inkSignature' after they are filling their initials :(

WebViewer Version:
While upgrading from 7.3 to 8.7.0
(we’re at the end of the upgrade - this is the last issue we’ve got and it’s blocking us from uploading)

Do you have an issue with a specific file(s)?


this is an image from our dev env, please ignore the first two errors - the third one is the relevant one

Can you reproduce using one of our samples or online demos?
No, we have a signature implementation of or own by examples from your code…

Are you using the WebViewer server?
no

Does the issue only happen on certain browsers?
all of them

Is your issue related to a front-end framework?
we’re working with angular 13 (soon 14) but it looks like it’s not related to us at all

Is your issue related to annotations?
yes - signature annotation

Please give a brief summary of your issue:
you’ve got a signature tool caching after clicking the draw (ink signature) type - users can’t sign because of this issue :frowning:

Please describe your issue and provide steps to reproduce it:
(The more descriptive your answer, the faster we are able to help you)
the issue is, when we’re moving from ‘inkSignature’ to ‘textSignature’ (stamp) for some reason somewhere in your code implementation you still trying to get the other type and this error appears (the image attached) and the user can’t sign, this is happening really deep in your library and it’s a showstopper for us for upgrading the library, please address this ASAP

in my investigation, this is where I got to that the but is occurring from:

what happening here is that we have first - added an initial’s signature, after that we’ve opened the ink signature (we’re preforming a click on the tab event initially to open this like that) and tried to sign - the user can’t sign in this situation because the signature tool itself is still thinks it’s ‘annot’ (associated annotation) is still a free text signature and it does not contain this ‘getPaths’ function - even after the ui has updated.
the guard function (IsEmptySignature) here is also failing since the ‘free text signature’ is filled by our user’s initials - from the beginning - this can not change since it’s like that in the prevues version and the upgrade need to be transperant to users.

what we need from you is a way to bypass this
and a fix if you can to make sure this could not happen again.

the upgrade we’re doing took us 3 months already because of weird issues like that please address this soon :frowning:

Thanks,
Mazi from Hibob.

Hey Mazi,

Thanks for reaching out.

This one is tricky to reproduce on my end because you have a custom signing workflow, but I think I have an understanding of what’s going on.

Regarding this point:

the guard function (IsEmptySignature) here is also failing since the ‘free text signature’ is filled by our user’s initials - from the beginning - this can not change since it’s like that in the prevues version and the upgrade need to be transperant to users.

Can you not clear the SignatureTool’s annot property when switching to the FreeHand mode? You should be able to clear it by calling setSignature with null. In 8.7 only one signature in the tool is supported at a time. Perhaps you can store your FreeText initial in a separate variable, clear the saved signature in the tool, and then allow your users to add a freehand.

In 8.9 we added a flow for initials, as well as a number of new methods. You can read more about that here. Starting in this version the tool can store one “full signature” and one set of initials at a time.

If the above does not help please share a runnable sample where we can reproduce the issue, as well as the steps to do so.

Best Regards,
Armando Bollain
Software Developer
PDFTron Systems, Inc.
www.pdftron.com

Hi @Armando_Bollain

I’ve tried to implement this:

I tried to do the clear, but the clearSignature(null) didn’t work for safari, and it did the trick for most browsers but safari. also ‘clearSignatureCanvas’ is not working here :frowning: any advice how can we reset the type so it will also work for safari?

we still see this as the annotation tool - annot instance and it looks like it wasn’t updated for safari users (never change - stays ‘stamp’ annotation type) - this happens occasionally, looks like timing issue, but I don’t want to keep playing with ‘setTimeout’ - it looks like just the wrong solution here

this is the code I’ve got for updating the type after the switch right after opening again the signature modal - it’s inside the : AnnotationClickedEvent filtered by the signature type:

                isInitialsSignature && tabBtn.click();
                console.log('BeforeTimeout',{SignatureCreateTool: this.api.documentViewer.getTool('AnnotationCreateSignature') as SignatureCreateTool})

                isInkSignature && setTimeout(() => {

                  console.log('Timeout beginning',{SignatureCreateTool: documentViewer.getTool('AnnotationCreateSignature') as SignatureCreateTool})

                  tabBtn.click();
            
                 (documentViewer.getTool('AnnotationCreateSignature') as SignatureCreateTool).setSignature(null); 

                  console.log('Timeout end',{SignatureCreateTool: documentViewer.getTool('AnnotationCreateSignature') as SignatureCreateTool})
                }, 0);

also - this is another error that is happening occasionally in safari (the one above the getPaths error - it also points to the inkSignature > handleFinishDrawing function, I think this might be for the same reason, that the annotation from the AnnotationCreateSigature tool still thinks it’s a stamp annotation and not inkSignature annotation:

any ideas?
Thanks!

another small update about this -
In 8.9 we added a flow for initials, as well as a number of new methods. You can read more about that here. Starting in this version the tool can store one “full signature” and one set of initials at a time.
I’ve tried also to upgrade since nothing seems to work in our case, you still have the same issue in the 8.9 version (we had other issues as well, we prefer not to upgrade to this anyway now) :frowning:
as you can see here from your code - still reference error - you’re trying to access the inkSignature function with stamp annotation reference in the signature tool “annot”, please help us resolving this issue!
is there any other way to solve this in version 8.7?
this is from the newer version, getting to the same result form your code:

Thanks, Mazi.

So the solution here was to just to reset the modal before it closes to the initial state - this happened when we’re opening the modal with initials and then programmatically we transformed the tab to the correct option.
the modal didn’t handle well opening with with ‘initials’ and moving to ink signature option right away programmatically - this was the root cause of this issue.
this is still a real bug in your area but the workaround is what I wrote here :slight_smile:

Hey @mazi.tradonsky,

Glad to hear you found a way around this issue. We can look at this further from our end but we need a way to reproduce this consistently in order to investigate it, as we do not see the issue in our demos. When you get a chance please share an sample where this issue can be reproduced consistently and we will look into it - usually a fork of one of our Github repo’s is the easiest way to do this. (example React repo).

Best Regards,
Armando Bollain
Software Developer
PDFTron Systems, Inc.