Docusign Focused is rendering an invisible iframe which makes complete app unusable

[felixhagspiel]

hey all,

This is more related to the docusign focused view javascript bundle, but I havent found a dedicated repository for that.

Reproduction:

1. Create an envelope with just one viewer, no signatures
2. Use that URL and send it to the docusign javascript SDK

   script.onload = () => {
       try {
         window.DocuSign.loadDocuSign(
           process.env.NEXT_PUBLIC_DOCUSIGN_INTEGRATION_KEY
         )
           .then((docusign: any) => {
             const signing = docusign.signing({
               url,
               displayFormat: 'focused',
             });
             signing.on('sessionEnd', (event: IDocusignEvent) => {
               if (
                 (event.sessionEndType === 'signing_complete' ||
                   event.sessionEndType === 'viewing_complete') &&
                 typeof onSigningComplete === 'function'
               ) {
                 onSigningComplete();
               }
             });
             signing.mount('#docusign'); // id of the div to render
           })
           .catch((err: any) => {...})

3. In the loaded iframe, click on "Agree"
4. Docusign SDK renders an iframe that is visually hidden, but overlaps the whole page, and nothing can be clicked. When I make the iframe visible via the devtools, I see this message:

5. However, the envelope is successfully submitted, which is especially bad, because it behaves like the user has agreed to the documents although he has not seen them. It just happened that the docs have been agreed on without clicking on the "Agree" button.

Latest Chrome Browser on Mac OS Sonoma 14.5

[GuilhermeFloresDocuSign]

Hello Felix.

My name is Guilherme and I'm a member of the DEV/API Support Team.

When there's no tab/fields for a recipient, it becomes a click to agree experience. That is by design.

Basically, when the "Agree" button is clicked, it finishes the signing session. You couldn't be able to click on that button more than once.

The document (PDF) should be loaded along with the "Agree" button. If the document isn't opening, the recommendation is checking if it loads properly by adding tabs/fields to it, as the problem could be related to the document preview rather than the Focused View's iframes.

Regarding the "invisible iframe", does that block you from clicking on the "Agree" button? Or are you still able to click on it?

If the button can be clicked even though you have that error in the invisible iframe, check in the Network tab in Developer Tools if you have ending/finishing info about the request.

[felixhagspiel]

hey Guilherme,

thank you for your quick reply. The PDF is loading with the Agree-Button, and I can click it. After clicking it the invisible frame is rendered.

[GuilhermeFloresDocuSign]

Hey Felix, so that would be all. The "Agree" button is basically informing the recipient about the document and clicking on it, it finishes the session and your application should treat it with event handlers, like :

signing.on('sessionEnd', (event) => { //code-here }

As soon as the "Agree" button is clicked, the session is ended and it means the recipient accepted/acknowledged the envelope.

The Focused View will try to redirect the signer to the 'returnUrl' page but you need to send the user to a new page using the sessionEnd before the iframe redirection attempt.

[felixhagspiel]

Hey, as seen in the code snippet we already handle sessionEnd, but it is never called when the user clicks on "Agree".

"The Focused View will try to redirect the signer to the 'returnUrl' page but you need to send the user to a new page using the sessionEnd before the iframe redirection attempt." Not quite sure what you mean by that. We are using the focused view which is embedded inside our application, and we do not want to redirect the user to any other page after he has agreed.

[felixhagspiel]

To narrow it down:

1. the main issue is that signing.on('sessionEnd', .... ) is never called when the user just has to agree. It is called correctly when the user has to sign.
2. The other issue is that the iframe that displays the error message is visually hidden and overlaps everything, which only can fixed by a complete reload of the page

[GuilhermeFloresDocuSign]

Good morning, Felix.

I'm still investigating what would be causing the behavior for the invisible iframe with the error.

About the 'sessionEnd' not being called, I couldn't reproduce that. It is always being called using the "Agree" button.

Would you be able to perform small test on your side?

  signing.on('sessionEnd', (event) => {
    alert("TEXT");
  });

Could you please comment your current code on the 'sessionEnd' section and use the above one? Basically, it will just pop-up an alert modal on the browser after the 'Agree' button is clicked.

In the meantime, I'll be checking internally what could be causing the invisible iframe.

Kind regards, Guilherme Flores Developer Support Engineer Working hours: (8am-5pm) Brazilian Standard Time (São Paulo)

[felixhagspiel]

hey

I already have that in place with console.log to test if the callback is being fired:

 const onDocusignReady = () => {
    try {
      window.DocuSign.loadDocuSign(
        process.env.NEXT_PUBLIC_DOCUSIGN_INTEGRATION_KEY
      )
        .then((docusign: any) => {
          console.log('CALLBACK');
          const signing = docusign.signing({
            url,
            displayFormat: 'focused',
          });
          signing.on('sessionEnd', (event: IDocusignEvent) => {
            console.log('SESSION END', event); // <- this is correctly logged on signature
            if (
              (event.sessionEndType === 'signing_complete' ||
                event.sessionEndType === 'viewing_complete') &&
              typeof onSigningComplete === 'function'
            ) {
              onSigningComplete();
            }
          });
          signing.mount('#docusign'); // id of the div to render
        })
        .catch((err: any) => {
          setToast({
            open: true,
            severity: 'error',
            message: t('errors.default'),
          });
          console.error('docusign catch error', err);
        });
    } catch (e) {
      setToast({
        open: true,
        severity: 'error',
        message: t('errors.default'),
      });
      console.error('Docusign loading error ', e);
    }
  };

Did you test your version with displayFormat: 'focused' ?

[GuilhermeFloresDocuSign]

Hey Felix,

Yes, I tested with displayFormat: 'focused'.

My test code looks similar, besides I'm not using event: IDocusignEvent, I'm just using event and the function is executed after the "Agree" button is clicked:

const signing = docusign.signing({
    url;
    displayFormat: 'focused',
    style: {
      branding: {
        primaryButton: {
          backgroundColor: '#333',
          color: '#fff',
        }
      },
      signingNavigationButton: {
        finishText: 'Custom Button Text',
        position: 'bottom-left'
      }
    }
  });
 signing.on('ready', (event) => {
    console.log('UI is rendered');
  });
  signing.on('sessionEnd', (event) => {
    console.log(event.sessionEndType);
   alert(); 
  });

[GuilhermeFloresDocuSign]

Hey Felix,

I was talking to the product team and they mentioned some bugs that were not fixed yet.

1. One is related if the signing session times out the sessionEnd event is not raised.
2. One related that sometimes the iframe is not cleared after sessionEnd event.

The product team would like to know if you can test their example which is located in https://github.com/docusign/docusign.github.io/blob/master/app-examples/embedded-signing/click2agree.js

They also have the code live in https://docusign.github.io/app-examples/embedded-signing/ which is basically using the 'app-examples' code.

The only difference between our codes and yours, is the 'event: IDocusignEvent'. Would you be able to test only with 'event'?

The 1st bug can only be reproduced with the session times out. I'm not sure if that is happening on your side, like, instead of having a 'sessionEnd' it is returning timing out event.

The 2nd bug would only happen if the 'sessionEnd' is being returned successfully. In your case, you mentioned it is not returning any data in signing.on( ).

Kind regards, Guilherme Flores Developer Support Engineer Working hours: (8am-5pm) Brazilian Standard Time (São Paulo)

[felixhagspiel]

hey,

This: event: IDocusignEvent is just typescript, and it is only used on application build, i.e. this will not show up in the javascript code that is triggered. Also, this works fine when there are no viewers but just signers, so I doubt that this is related to the issue. I will have a look at those examples, but atm it looks like we will abandon the focused view and just redirect the user to a new tab to save time. Will update you once I have tested it

[felixhagspiel]

@GuilhermeFloresDocuSign would it be possible to schedule a short call with one of your devs?

[GuilhermeFloresDocuSign]

@felixhagspiel Yes, I can send a Zoom link. I'm located in Brazil. Would one of your devs be online around 11 AM BRT time? That would be 3 PM London time.

[felixhagspiel]

@GuilhermeFloresDocuSign yes, I am available. please send an invite to hello@felixhagspiel.de

[GuilhermeFloresDocuSign]

@felixhagspiel Thank you for your time today! Can you share the EnvelopeID that we used today during our tests? In case you cannot find it, send a new envelope with no tabs and grab its ID.

I'll be contacting the product team in the mean time.

Kind regards, Guilherme Flores Developer Support Engineer Working hours: (8am-5pm) Brazilian Standard Time (São Paulo)

[felixhagspiel]

@GuilhermeFloresDocuSign 73ae80cd-5929-414b-9e7f-e0085f0ee202 (its a new one)

[GuilhermeFloresDocuSign]

@felixhagspiel We were able to finally reproduce the issue. The root cause is the Signer type, which your app is using the "Certified Delivery" signer type (https://developers.docusign.com/docs/esign-rest-api/esign101/concepts/recipients/).

We tested and we got the same exception.

To fix it on your end you need to change from Certified Delivery to "Signer" and that should fix the errors you are seeing.

We are confirming with the product team if we have that information public somewhere and in case we don't have, we will ask to update our documentations and mention that the signer type must be "Signer", otherwise, the "Click2Agree" feature will not behave correctly.

Kind regards, Guilherme Flores Developer Support Engineer Working hours: (8am-5pm) Brazilian Standard Time (São Paulo)

[vincent-milia]

Hi there, I'm Vincent, a colleague of Felix. Thanks for the answer. I think changing the recipient type from Certified delivery to Signer will not solve the issue for us. As far as I know, a signer must always sign, e.g. it is not possible to omit signing anchors for recipients that are signers. We specifically want to use the certified delivery role (i.e. have recipients that DO NOT sign, but only acknowledge that they saw the signed document).

Can you confirm that the focused view is working for Signers only, and the other roles are not working for now?

Best regards, Vincent

[GuilhermeFloresDocuSign]

Hi @vincent-milia

The test that we've done was using the "signer" type and we didn't send any fields for signature.

Here's an example:

{
    "compositeTemplates":
    [
        {
            "inlineTemplates":
            [
                {
                    "documents":
                    [
                        {
                            "documentBase64": "doc",
                            "documentId": "2",
                            "fileExtension": "pdf",
                            "name": "Lorem Ipsum"
                        },
                        {      "signerMustAcknowledge": "view_read_accept",

                            "documentBase64": "doc",
                            "documentId": "1",
                            "fileExtension": "pdf",

                            "name": "MyCompany Quote",

                        }
                    ],
                    "recipients":
                    {
                        "signers":
                        [
                            {   
                                    "emailNotification": {
                                    "supportedLanguage": "pt"
                          },
                                "clientUserId": "1000",
                                "email": "email",
                                "name": "Gui Viana",
                                "recipientId": "1",
                                "roleName": "Signer1",
                                "tabs":
                                {
                                }
                            }
                        ]
                    },
                    "sequence": "2"
                }
            ]
        }
    ],
    "emailSubject": "Envelope - Email",
    "status": "sent"
}

Basically, you add a "tabs" object but you don't include/assign any tabs for the signer. It is a bit different to way it is working right now because Felix showed that your application is calling the "SenderView" before sending it.

Using the above method, you send it directly without creating the "SenderView", so your application would just need to pull the documents to include in the body of the request and no needing to call "SenderView".

When the recipient opens it, it will provide the same "Click to Agree" behavior and no fields for signature. Just the same way it is happening right now for you, but of course without that problem where the "signing.on( )" isn't being executed.

Can you confirm that the focused view is working for Signers only, and the other roles are not working for now?

I'm still waiting the feedback from the product team. We got the same exception in the background using that signer type (certified delivery).

If it's a bug, we will raise a bug ticket to the product team. If it is expected to work that way, we will ask our technical writers to include that in our documentations.

[GuilhermeFloresDocuSign]

@felixhagspiel @vincent-milia

I got the feedback. According to the development team, the Focused View was not intended for Certified Delivery recipient type.

I created an enhancement ticket so they could investigate further, but at this moment, the Focused View using click to agree experience will not work with Certified Delivery recipient type.

About the ticket, I cannot provide any ETA, but the owner of the DocuSign Account can contact the Account Executive of the account and ask what's the status of C2A-3508 (or open a support ticket to check the status).

Kind regards, Guilherme Flores Developer Support Engineer Working hours: (8am-5pm) Brazilian Standard Time (São Paulo)

[vincent-milia]

Hi Guilherme, alright, then we will wait and use the "regular" embedded view for now. thanks a lot for the support. Best, Vincent