1000 log messages "Icon being re-registered. Ignoring duplicate registration." using Fabric React in SPFX webpart solution

[frevds]

I'm having a SPFX webpart solution using React and Fabric UI. In the browser log I get more than 1000 warnings about icons being re-registered. I attempted to deactivate these using the GlobalSettings for icons but that did not help.

Is this normal or am I having some ill-configured packages?

[frevds]

If that is indeed the case for any solution made with Fabric in SharePoint, then Microsoft is not acting professionally here. We are developing solutions. It is hard to explain to our customers (big companies) to ignore 1000 ugly warnings in the log, and it is extremely annoying to have them in there (takes memory and time) and no way to disable them. If I want to debug my solutions in Edge, I have to wait 1 minute for my log messages to appear after all these warnings, due to the slow processing.

[salascz]

Agreed, those warnings are very annoying during development...

[frevds]

You mean they don't appear in production?

[kciabc]

Totally agree. These warnings suck up resources and lead to poor page load performance.

[pedropablo]

I think this is a SharePoint Online issue, because in "native" pages it also shows the warnings. Even the new sharepoint admin page shows them

[frevds]

Interesting @pedropablo, thanks for pointing that out. It seems this is happening with every clientside page (e.g. when creating a Site Page in Pages). Apparently whenever the Fabric React bundle is loaded, since the icons were registered before by SharePoint natively. The Fabric GlobalSettings defaults for icons should be adjusted so that these warnings don't appear on the console.

[kingfu]

Agree. Needs to be a way to disable. I tried the suggestion from this article: https://github.com/OfficeDev/office-ui-fabric-react/wiki/Using-icons but first option doesn't seem to work and second option won't compile.

[frevds]

As pointed out earlier this cannot possibly be done by us in the extension we control, since these warnings already occur on the SharePoint side when the ClientSidePage is loaded. This is what MS should add to their call to initializeIcons.

Both calls compile for me, none have any effect. I tried the same using the GlobalSettings class.

[dzearing]

@frevds the problem is that initializeIcons is being called multiple times. It is not pointless that there are complaints here; but something is causing an unanticipated behavior.

Whatever information you have to repro would be useful. Trying to get a dev here to help out on the SP side.

[frevds]

@dzearing Yeah, a SP dev taking a look at it would be great. I do have these warnings in the log for a plain ClientSidePage (Site Pages library > New Site Page). Apparently SharePoint registers the icons on its own and then loads the Fabric UI react bundle separately and registering them again. What exactly goes on under the hood is anybody's guess.

On the Fabric side - would it be possible to have a time-based aggregation of these warnings? Instead of having literally 1000+ messages of the same wording in the log for each icon one could put 1 message with 1000 icon names in it. Particularly in the Edge browser it takes more than 1 minute to actually poll all those warnings into the console (making debugging annoying, for every time you refresh the page you have to wait 1min to find your own log messages).

[dzearing]

I am literally working on this fix right now; pr out shortly.

[frevds]

Great, looking forward to it.. which reminds me, this won't be coming straight into SharePoint anytime soon I'm afraid. But good to know that eventually it will.

[dzearing]

Separately, there are devs now investigating on the sppages side to identify root cause.

[dzearing]

The fix will be published in Fabric 6 tonight; I'm looking at cherrypicking into 5 and seeing if we can get that rolling if the devs investigating don't find the root cause sooner.

[MaheshakaMudli]

@dzearing Fabric 6 is not supported in spfx 1.6+. Is there any other alternatives to get rid of these warnings as it is impacting the page performance in production.

[AteetAgarwal]

SP 2016 is using SPFx 1.1.0 and office-ui-fabric-react 2.31.0. This issue exist there too. What is its possible solution?

[magonzalezm]

I have the same problem, the more than 1000 warnings come from this js: https://spoprod-a.akamaihd.net/files/sp-client-prod_2018-11-09.013/office-ui-fabric-react-bundle_71d81bf8e2308355fb1b83074045e6a9.js I use spfx with different versions 1.7 and 1.1.

[salascz]

The issue has been solved already on Fabric side. Now we have to wait till SharePoint guys updates their packages on their side...

[AteetAgarwal]

I followed the blog https://github.com/OfficeDev/officev-ui-fabric-react/wiki/Using-icons to fix the issue. SPFx v1.1.0 doesn't support these classes, so tried with v 1.7.0 but that doesn't solve the issue.

[salascz]

Well I got those warnings even for empty workbench page...

Your issue might not be caused by your code.

Actually, I do not know about any way, how to force the rest of the SharePoint page to use updated Fabric even when you use it for your code...

[frevds]

I'm glad to announce that as of today the issue is gone. SharePointOnline was updated yesterday (to React16, probably with Fabric6) and this issue was addressed as well. I do no longer get any of these warnings, even on old pages and with Fabric5 custom solutions. Thanks to everybody involved for getting this solved so quickly.

[dzearing]

I believe they're stlil working through TypeScript updates first before Fabric 6, and that the cherrypicked fix in 5 got updated there.

[frevds]

Possibly, I have no idea how to check. I will try to upgrade my solution to React16 and/or Fabric6 tomorrow and see what happens. What I can see from the manifest in the page source is that they are loading an internal version of the SharePoint framework in version 1.8.0, which does not exist on npmjs.org yet (1.7.0 being latest). The source for the office-ui-fabric-react-bundle alias OfficeUIFabricReact is at https://spoprod-a.akamaihd.net/files/sp-client-prod_2018-11-09.013/office-ui-fabric-react-bundle_71d81bf8e2308355fb1b83074045e6a9.js, but it does not contain any version numbers, so I don't know which Fabric version that is (would have to compare members and check for features only introduced in Fabric6).

[frevds]

@dzearing gotcha - console log in SharePoint Online:

Thanks for aggregating that one and saving us a lot of log space. I'm gonna close this ticket.

[MaheshakaMudli]

@dzearing , @frevds : We are facing this issue now in our tenant. In Edge, the browser hangs while this logs are been printed. We are using spfx 1.6 with react 15 and office fabric 5. Can this be resolved at our end in any way. Please see the screenshot below.

[frevds]

@MaheshakaMudli Hm no, you're not facing that issue. Originally we had 1483 individual messages in the log - your screenshot indicates that these messages are already aggregated into one, which was the improvement ("Some icons were re-registered […] + 1483 more"). There will always be a gazillion other messages in the log, and only Edge seems to have a problem handling many log messages when the F12 console is open, which it streams in an torturous slow way (1 chunk of 10 each second only or so).

[MaheshakaMudli]

@frevds: currently this is in production environment and lot of our clients use edge browser resulting in compliants. Is there any workaround available to cope with it in edge.

[frevds]

@MaheshakaMudli Your customers rarely have the F12 console open. So this can't be the issue. In other words - Logging does not happen if the F12 console isn't (and was never) opened for the page - the code runs without debug instructions in an optimized profile. You should investigate what else might cause the problems during load, maybe some synchronously loaded resources.

[frevds]

@dzearing Could the browser freeze described by @MaheshakaMudli have anything to do with the way the messages are aggregated using a timeout? Indeed this is independent of whether the console is open or not, and on rather slow computers this could cause issues if resetting the timeout is a costy process that has to be executed 1483 times. You might want to aggregate the messages synchronously in the array and start one single timeout that triggers several seconds away to display the aggregated chunk, rather than resetting it.

[msft-github-bot]

Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues