Office-js: OWA add-in error: We're sorry, we couldn't access [add-in name]. Make sure that you have a network connection. If the problem continues, please try again later

[sarea]

We're sorry, we couldn't access [add-in name]. Make sure that you have a network connection. If the problem continues, please try again later
This error message starts showing on IE11 and we couldn't reproduce it.
Then it starts showing on Chrome as well, it happened randomly, but there's a way to reproduce it in one case only:

• having onsend functionality that will trigger a dialog when the send button clicked
• add debugger in the dialog.
• trigger (press) send, that is going to show the dialog, therefore the debugger.
• leave it for more than 5min (dialog lifetime).
  Now I expect the dialog to be closed automatically after ~5min, and that happened but the error message is shown as well.
  But still, sometimes this error message is shown randomly once the send button clicked! it shown instead of this message: [Add-in name] is working on your request.
  I cant troubleshoot/log or even control the add-in at that time, it happened before the add-in gets initialized, however, I can see in the Devtools in Chrome an error log (see below) from your side (I'm not using React in our add-in).

Knowing that this issue is affecting our costumers and preventing them from sending messages.
And again, the step to reproduce this issue is for one case, but costumers are getting it when they click send.

Environment

• OS: Mac, Windows
• Browser: Chrome, IE11

Useful logs

• Console errors:

react-dom.production.min.js:114 Uncaught TypeError: Cannot read property 'extension' of null
    at IFrameableDialog.tsx:43
    at index.module.js:200
    at index.module.js:178
    at an (mobx.module.js:3321)
    at e.track (mobx.module.js:3525)
    at h (index.module.js:176)
    at index.module.js:200
    at Ui (react-dom.production.min.js:148)
    at va (react-dom.production.min.js:166)
    at ma (react-dom.production.min.js:166)

[exextoc]

Hi, thanks for reporting this issue. Does this happen a few times randomly, when sending an email? We are not able to reproduce the bug on our end. Could you explain what you mean by "Add debugger in the dialog" in your repro steps? And is it possible for us to get a test account with this add-in installed, so it's easier for us to reproduce this?

[sarea]

Hi @exextoc, thanks for the quick reply.

• Yes, it happens a few times randomly, the reported case that we got from our customers is in IE11, they were getting the message when then press send and getting blocked from sending, but I was able to reproduce it in a different flow as I described above.
• Regarding "Add debugger", I just meant to add debugger statement in the code to stop executing, this just to show you the message that I got and the error in dev-tools in Chrome.
• It is possible to have a test account, but I have made a simple owa add-in app https://github.com/sarea/test-owa
  I've already added a debugger, so you just need to press send and leave it for ~5min.
  Another thing, if you leave the right pane open before doing the previous steps, you will get a weird white plank in the right pane after getting the error message.

[exextoc]

@sarea are there any specific instructions for installing the add-in?

[sarea]

Hi @exextoc

• clone/download the repo.
• npm i
• npm start
• got to https://localhost:8443/v3
  you will get Your connection is not private press advance and proceed to that domain.
• go to owa, install the add-in as a file from the generated manifest in the src folder.
  note: the manifest will be generated after starting the app

[exextoc]

Thanks, we got it working. But we couldn't reproduce the same issue(s) you're describing. When we click on send the dialog always appears. When we let it time out, the error message that is shown is: "The add-in OWA (localhost) has prevented this item from being sent." which is expected, from this scenario.

We cannot see the "we couldn't access [add-in name]" error message. We're suspecting this is a connectivity issue - are you facing this problem when hosting the add-in on localhost? When you're getting this error, can you make sure you're able to access the add-ins resources (and pages) from a browser tab?

[sarea]

Thank you @exextoc , just one last question, did you get the debugger in this line? and did you press continue? if so, could you please try the same thing but without continuing the execution of the debugger, just let it pausing, and you need to have the devtools open, otherwise, the debugger statement is going to be ignored.
If you already did, then it's really weird, my colleague were able to reproduce it!
This issue is not only on the localhost, but it's also on our environments. and I can access the pages from the browser tap resources.
Thanks

[exextoc]

No, we did not hit the debugger anywhere. Do you only encounter this issue when execution is blocked by the debugger?

[sarea]

Yes, and like I said before, this is one case to reproduce this issue which is not going to happen with the costumers as we trigger the debugger.
The other case is when the user presses the send button and got the same notification message, but I was not able able to reproduce that issue because it's happening randomly and only on IE11 as far as we know from our costumers.
So the debugger case is only to see the error message in the notification bar and the one in the console log, so maybe this is helpful to see the issue in general.

[exextoc]

@sarea Yes we are able to repro with the debugger. But in the case of debugger as we are waiting for 5 mins there could be a timeout happening. Does the flow reported by your customer also involves waiting or it happens on normal send?

[sarea]

@exextoc there's a small issue that the customer had simulating the debugger use case. but that one can be fixed by fixing the bug from our side as it happened from our side first.
so as a conclusion from the debugger issue:
once the browser stops executing javascript with the dialog open we are going to get the message.
But the one that has been reported by our customers more often (which we have more concern about it) is when they press send they got the message and they were not able to send the message, there's no way to debug it from our side as the add-in did not initialize from the first place.
Knowing that the customers who reported that issue only uses IE11, we did not get the issue from other customers that using another browser yet.

[exextoc]

Is the console error shared in the useful logs section from the send scenario? If not can you get the console log from your customer for working and failure scenarios?

[sarea]

There is no console error when the issue happened with the customer on IE11.

[exextoc]

Can you share the actual manifest file so that we can install the Add-in and replicate the issue?

[sarea]

The manifest is going to be generated in the repo that I've shared with you, it's going to be in src folder once you do npm start or you can access it by going to https://localhost:8443/v3/manifest.xml after starting the app (npm start)

[exextoc]

@sarea Thankyou. By actual manifest we were referring to the one which is being used by your Customers and not the test Add-in. Is it possible to share the same?

[sarea]

This is exactly the same, the only difference is the company name, description, and the manifest ID

[exextoc]

@sarea We would like to try hitting the same end point which is used by Customer instead of localhost and see if the issue occurs as we are not able to replicate the issue using localhost. So, we require the manifest with the end points where Add-in is originally hosted. Also, how soon does the error message gets displayed after the Send button is clicked?

[schmkr]

Hey there, I'm a colleague form @sarea and we have now identified the root cause of this report.

It happened in two scenarios.

The first scenario happened when our add-in would load too slow and registering the onSend-event handler did not happen within an x (milli)seconds. This scenario happened we can address very easily by defining the handler already in the head of the DOM and when the handler triggers, assign the event variable to a global variable.

The second scenario happens when our add-in opens a dialog (using Office.context.ui.displayDialogAsync()) but the user becomes inactive and we never call the completed callback on the on-send event. We have built-in a setTimeout() for a little less than 5 minutes as that is what we learned was the maximum time a dialog could be open. That timeout does not always seem to execute and thus, most probably, also resulting in the same error from the title of this issue.

So we now know what is causing this, our question would now be more on the specification and recommendation side:

• what is the timeout for registering the onSend event handler before Outlook will abort the onSend event and display the error?
• what is the timeout before the completed() has to be called?
• do you have any recommendation on how to handle inactive user that have a dialog open from an onSend event where we would still call the completed({ allowEvent: false }) before Outlook closes the / terminates the add-in?

Thanks.

[exextoc]

onSend add-ins are treated in a similar manner as every other add-in. So the timeout for onSend add-in is also 5 minutes. You have to register the onSend event before 5 mins.
Regarding the timeout which you are setting might not be same as 5 mins of the add-in timeout as the add-in timeout starts as soon as it is launched so you try setting the value less than 5.

[Saarnaki]

Is there any way to bypass this timeout? Is it reset by some action?

Also, can you give us any recommendations, like schmkr wrote?

do you have any recommendation on how to handle inactive user that have a dialog open

[ArtsiomLysianok]

Is there any way to bypass this timeout? Is it reset by some action?

Also, can you give us any recommendations, like schmkr wrote?

do you have any recommendation on how to handle inactive user that have a dialog open

I had the same issue with the dialog window, if it's your case you can create it through task pane. (e.g. trello add-in uses that way). If you have implementation questions you can mail me.

[exextoc]

Currently, we do not have any recommendations for cases where user becomes inactive and keeps the dialog open for long time. We have 5min timeout by default and there is no dynamic way to change it.

But if you have certain use-cases where users are expected to be inactive, please file a user voice feature request for this. We track Outlook add-in feature requests on our user-voice page. Please add your request there. Feature requests on user-voice are considered, when we go through our planning process.