Adding global window.onerrror event handler for Consumer iFrame and babel config.

[shriniketsarkar]

Summary

Babel Config change : Added in the useBuiltIns to the config to ensure any missing polyfil is available. Global Error event handler : Added a window.onerror event handler to the consumer iFrame to handle any script errors that are unexpected and unhandled in the code. This will ensure that the user does not see the script error thus improving on the user experience.

Additional Details

Babel Config : This change was needed because in IE11 browser while testing SMART on FHIR applications in MPages the Object.entries function was undefined. This babel config change ensures to add the necessary polyfills if the functionality is being used. Without this change SMART apps would not load in MPages when consuming the 1.10.1 version of xfc.

Global Error handler :

• Scenario : If xfc is used in a nested iFrame architecture (as in SMART apps in MPages) we have 2 instances of xfc being used for performing the security handshake. When the inner iframe is loading/framing a 3rd Party application it results in sending postMessage to the outer iFrame for resizing, etc. In such a workflow if the outer iFrame is reset/reloaded/cleared during a tab sorting event in the other iframe's container it results in reloading of the outer iFrame without methodically clearing/unloading the nested inner iFrame. If this behavior happens fast enough we have observed that it results into a race condition where several messages are being sent from the nested iFrame while the other iFrame is still reloading resulting into script issues. Since we do not have any control over when the outer iFrame will get cleared we cannot initiate a cleanup before this happens. This results in the user seeing a script error that they have to click through until the application loads.

• Script Errors : The script errors observed in such a race condition are Date is undefined, Object expected., parseInt is undefined, resolve is undefined on a Promise, etc.

• Consideration : Since we know that the last queued reset/clearing operation in the user's workflow will result in a successful load of the application being framed we can suppress the script errors for a better user experience.

• Solution : Adding a global event handler using window.onerror catches such unhandled errors and logs them to the console.

[shriniketsarkar]

@mhemesath , @divyaashritha , @foxannefoxanne Can you take a look at this PR and provide your thoughts?

[jvarness]

According to the mozilla docs: https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onerror

This implementation might be hiding what the original error was to begin with. This code prevents the default error handler from executing because it's returning true, and it also doesn't log out any information besides the line number, message, and URL. Column number could be very helpful here since a lot of production JS is minified, and logging out the original error could help reveal important debugging information.

I'm also curious if window.onerror needs to be checked for existence. Cerner I believe supports IE 11+, and onerror has been a global handler since IE9.

[shriniketsarkar]

According to the mozilla docs: https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onerror

This implementation might be hiding what the original error was to begin with. This code prevents the default error handler from executing because it's returning true, and it also doesn't log out any information besides the line number, message, and URL. Column number could be very helpful here since a lot of production JS is minified, and logging out the original error could help reveal important debugging information.

I'm also curious if window.onerror needs to be checked for existence. Cerner I believe supports IE 11+, and onerror has been a global handler since IE9.

Since the JS is minified the user cannot really do anything other than clicking Yes or No on the error dialog to make the error go away. By returning with a true we are preventing the error thrown from surfacing. In this particular case that is exactly why we are wanting to add this error handler. Once the error happens it will get caught here and then logged, to avoid it from surfacing for the user.

if (window && !window.onerror) {} check should take care of the existence of the onerror function before setting it.

@jvarness I have added stack trace and other details to the log.

[jvarness]

@shriniketsarkar thanks for adding the original error and the column number! I'm not a collaborator on the project so I can't approve the PR but I do in spirit.

[shriniketsarkar]

@roxjcalderon what would be the next steps to get this merged in and released ?

[mhemesath]

I don't believe this error handling logic should be packaged into XFC. This isn't capturing XFC specific errors, so if a consumer of XFC wants this behavior, it should package it within its own libarary.