Application customizer fails to load sporadically

[wizneeraj]

Target SharePoint environment

SharePoint Online

What SharePoint development model, framework, SDK or API is this about?

💥 SharePoint Framework

Developer environment

Windows

What browser(s) / client(s) have you tested

• [ ] 💥 Internet Explorer
• [X] 💥 Microsoft Edge
• [X] 💥 Google Chrome
• [ ] 💥 FireFox
• [ ] 💥 Safari
• [ ] mobile (iOS/iPadOS)
• [ ] mobile (Android)
• [ ] not applicable
• [ ] other (enter in the "Additional environment details" area below)

Additional environment details

• browser version : Chrome 100 & Edge 100
• SPFx version: v1.13
• Node.js version: 14
• etc

Describe the bug / error

We are having a Header component in SPO using Application Customizer. The component loads fine for the first time and then for following refreshes fails with the below error.

Refused to execute script from 'https://contoso.sharepoint.com/sites/Appcatalog/ClientSideAssets/adc45aee-4225-4dbb-9d6a-c42904c8bd65/SPOHeaderApplicationCustomizerStrings_en-us_09d7816cec5d664c5791eb382892222b.js' because its MIME type ('text/html') is not executable, and strict MIME type checking is enabled.

Could not load spo-online-header-application-customizer in require. Trying in system.js. Error: Script error for: fd7e3581-8ccf-4780-b3d1-67a0e4cd17c7_0.0.1/spoHeaderApplicationCustomizerStrings
http://requirejs.org/docs/errors.html#scripterror
    at B (eval at e (sp-pages-assembly_en-us_5e35b6d337d496dfb5f856b9e0c438e0.js:70:848251), <anonymous>:8:252)
    at HTMLScriptElement.onScriptError (eval at e (sp-pages-assembly_en-us_5e35b6d337d496dfb5f856b9e0c438e0.js:70:848251), <anonymous>:30:244)

This is happening only in Chrome but not in Edge browser. If I clear cache in Chrome it works but successive refreshes will not load the component and the above errors will be present in the Chrome browser console.

Steps to reproduce

Sporadic and happening only in Chrome

Expected behavior

N/A

[ghost]

Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.

[AJIXuMuK]

@wizneeraj - could you please try adding ?sw=bypass on a successive refreshes and see if it's still failing? Thanks!

[wizneeraj]

Yes, adding ?sw=bypass and then refreshing page loads the Application Customizer's Header component fine. So what that does it indicate as I couldn't find much from the internet about this querystring.

[wizneeraj]

@AJIXuMuK - Based on further investigation found that the js files were loading from chrome's cache which were few days old. On deleting the SPOHeaderApplicationCustomizerStrings_en-us_09d7816cec5d664c5791eb382892222b.js file from the chrome cache is fixing the issue. But, I cannot use this solution for all the other users on the tenant who are facing this issue sporadically.

Is there a way to fix this issue, so that other users do not face this issue? Also, I am sure I will be facing the issue as well after few days.

[demyren]

Hi @wizneeraj - is this a new customizer or an existing customizer that stopped working? Would it be possible for you to share a trace (Fiddler/har file) of a failure loading the customizer? That would be useful for my investigation.

Also, from the trace that you shared, since the URL in that trace points to "contoso.sharepoint.com", I just wanted to confirm; you manually replace the actual URL with this example URL?

It also seems from that trace that the cache entry for the script file was unexpectedly in HTML format. I am wondering if possibly, the original request that cached the strings file got throttled and returned a HTML throttle page. BTW, it is not a requirement but in general, hosting the customizer on a CDN may present better performance of the customizer. If the original issue was related to throttling, then it would also resolve that issue.

[wizneeraj]

@demyren - It was an existing customizer that stopped working for random users in Chrome. I went into cache storage where the content type of SPOHeaderApplicationCustomizerStrings_en-us_09d7816cec5d664c5791eb382892222b.js was saved as text/html. I removed the file and refreshed the page and ever since then the customizer started working fine. I am not sure how the content type was saved with a wrong value, may be it happened due to throttling, which I am not sure. Is there any way to fix it from my end or is it a chrome issue? Anyways to handle it better in the customizer's code?

Yes, I replaced the URL with contoso.sharepoint.com for privacy reason instead of the original URL.

[demyren]

@wizneeraj I see, thank you for the information. We haven't had any impacting changes here as of late. That said, I am suspecting that the original request to SharePoint to load the file indeed resulted in a throttling error and incorrectly caused the service worker to continue serving the cached HTML result.

We will address this problem with a change that ensures that whenever we cache your script files into cache storage, we ensure that the resulting response is not a throttling error.

For optimal performance and delivery to clients, you may consider moving your customizer to CDN. That said, we certainly hope to land the change this week that will prevent these bad, throttled responses from getting cached. I will update the thread again with information on rollout of that change once we have completed it.

Thank you for reporting the issue and allowing us make the product better!

[wizneeraj]

@demyren - Thanks, looking forward to the fix.

[wizneeraj]

@demyren - Has the fix been deployed ?

[demyren]

@wizneeraj, the change will start deploying on 10/24 and will finish by 10/28. I will post back when the deployment has completed! I apologize for the delay.

[wizneeraj]

Thanks for the update @demyren

[mgrosperrin]

Hello @demyren, Not sure how it is related to this issue, but we have similar issue with WebParts: sometimes, some of them failed to load with "strange" errors (HTTPS certificate issue for a file hosted in the Azure CDN, unable to load empty component). When this happens, we also note that the loaded script files are from different versions of our package:

Can you confirm the fix you mentioned will work for this case (or should I open another issue)?

[demyren]

@mgrosperrin I'm afraid that does not sound related - and frankly not something I think I have seen before. Do you typically see it occurring as you deploy a new version of your web part? Do you use any authentication on your CDN or are the script files anonymous requests? If you are able to collect a Fiddler or HAR trace, you can send this to me ([email protected]).

[mgrosperrin]

@demyren I create a new issue with an HAR from a test environment #8519

[wizneeraj]

@wizneeraj, the change will start deploying on 10/24 and will finish by 10/28. I will post back when the deployment has completed! I apologize for the delay.

@demyren - Has the fix been rolled out to all tenants ?

[demyren]

@wizneeraj The change was delayed by another week but is starting to deploy to Prod tomorrow 1/11. My apologies for this additional delay.

[wizneeraj]

@demyren - Is the fix rolling out from Nov 1st?

[demyren]

@wizneeraj, yes, the fix started deploying to Prod this week. The deployment should complete fully by 11/7. I will post back when it is completed.

[wizneeraj]

@demyren - Please let me if the fix has been rolled out completely.

[demyren]

@wizneeraj The build has finished deploying to Prod. Note, you may need to return to SharePoint and wait a few seconds for the new service worker to install and activate. Followingly, the reported problem has been addressed and will prevent throttling responses from getting inserted into the cache.

Thank you for reporting the issue, and for your patience when the fix got delayed! I hope you see things working smoothly from now on. Should there be further problems, do not hesitate to reach back out to me.

[wizneeraj]

@demyren - Thanks for the update. Will check from my end and let you know. Meanwhile, when you say "return to SharePoint", is there any specific you are referring to, or accessing any site will make the new service worker to install and activate?

[demyren]

@wizneeraj, thank you. I hope it will work out well for you. Yes - returning to any site will do, and should install the latest service worker.

[wizneeraj]

@demyren - We are seeing this issue again in our tenant where the js file is getting tagged with a wrong content type in the browser cache. Its getting tagged with text/html type instead of application/javascript. Was there any rollbacks to the solution deployed ?

[demyren]

Hi @wizneeraj - I'm sorry to hear you are running into this problem again.

We have not made any changes since we deployed this code fix. The fix ensures that if a file is served from SharePoint, we validate the content type of the response (Content-Type header) to match the acceptable content types as specified in the Accept request header.

If you open the Site- cache storage, can you see your file in there? What is the content of this file, is it again the throttling HTML response instead of the expected JavaScript?

If it is, it would be great if you could first copy it or screenshot it, then delete that file from the cache and retry. Does that re-cache the file correctly? If you can send this to [email protected] I can review the request and response of the incorrectly cached file and see if I can understand why we ended up caching this file even if SharePoint returned a throttling error.

Thank you.

[msoumit]

@demyren - Commenting into the thread as we have faced a similar issue where system.js issue happening for app customizer and webpart. On hard refresh it works fine. Adding ?sw=bypass is working fine as well as mentioned above. However, we can't force all end users to add ?sw=bypass. Only happening in Chrome. We have an example of site getting throttled as well. Chrome cache is showing content-type as "text/html" as well.

Almost all of the above discussions are pretty much matching with our case. It seems that Chrome is caching throttle response as well. I saw you have deployed the latest build in production during November. However, we are using Chrome v105 which was released in August. Latest Chrome version is v108. Do you feel it might be due to Chrome version as well ?

Just out of curiosity @wizneeraj - Is it fixed for you or you are still seeing throttle response cached in Chrome?

[wizneeraj]

@demyren - We are still seeing the issue as the old cached value is not getting removed from the user's browser. There was a wrong cached content type on 12th Oct which is not yet removed and causing the issue. Manually removing the cache is fixing the issue. However, we have a very large user base and manually fixing it for everyone is not the solution. Doesn't the Cache storage get rebuilt on a periodic basis?

@msoumit - We are not facing the issue for any new users. We are seeing it only for the user's who have the old cached content.

[AJIXuMuK]

@wizneeraj - sorry for the delay. Are you still experiencing the issue? @demyren - could you please keep in touch?

[demyren]

@msoumit, are you experiencing this issue still?

[wizneeraj]

@AJIXuMuK - We had to repackage the solution with a new version number. Then remove the existing solution completely from the App Catalog and the recycle bin. Then we deployed the solution with new version number, post that we did not see the issue.

[msoumit]

@demyren We were facing same issue with both our app customizer and webpart. We have only one app customizer and a webpart in our application. Usually, it was user specific. At random interval, random users used to face this problem. Initially for a couple of weeks, sw=bypass was working fine but later that stopped as well. Our webpart gets modified every sprint and a new version gets deployed every two weeks removing the older one. But the issue was still there. Our app customizer didn't have any enhancement for a long time. So, the version stayed same. However, in our latest sprint, we have decommissioned our app customizer fully. But we will keep on monitoring in case the webpart is still giving the same issue of caching the throttle page.