Fluentui: New require.js of SharePoint removes styles of Office UI Fabric

[BigEaseGueldi]

Bug Report

• __Package version(s)__: 4.35.1
• __Browser and OS versions__: All browsers, Windows 10, macOS, ...

Priorities and help requested:

Requested priority: (Blocking, High, Normal, Low)
Blocking

Products/sites affected: (if applicable)
All SP Online classic pages on tenants with the require.js version below which are using Office UI Fabric components.

Describe the issue:

The following version of require.js will remove the injected CSS of Fabric UI Components:
spoprod-a.akamaihd.net/files/odsp-next-prod_ship-2017-08-11-sts_20170818.001/require-951f856e.js

(it is OK with 2017-08-04-sts_20170815.001 which we still have on another tenant)

Steps to reproduce:

1. Open any browser that can block certain files from loading (e.g. Chrome)
2. Block the file -> components will be rendered correctly
3. Unblock the file -> CSS for components is missing completely

[olemp]

Blocking the file https://spoprod-a.akamaihd.net/files/odsp-next-prod_ship-2017-08-11-sts_20170818.001/listviewdataprefetch-784d3572.js makes the components render correctly for me.

For me, this issue is for subsites only. Works for root webs. No idea why!

[mlp73]

Yes. Same here. But need to find out how to force another version of it over.
(We have the issue also on root webs here)

[olemp]

This would be a quickfix:

let css = "";
let styles = document.querySelectorAll("style");

window.setTimeout(() => {
    styles.forEach(style => css += style.innerText);
    let styleSheet = document.createElement("style");
    styleSheet.innerText = css;
    document.body.appendChild(styleSheet);
}, 1000);

It stores the injected <style> tags before they're removed by require.js or listviewdataprefetch, and appends them to a separate <style> tag in document.body.

Trying to find out why the injected style tags are removed from document.head. Looks like 23 style tags are removed when require.js or listviewdataprefetch are loaded.

[olemp]

Another finding: It differs from tenant to tenant even with the same listviewdataprefetch and require.js loaded. Works on one, fails on the other.

[phettz]

Another possible "hack" is to change the require path before it loads. If you have scriptlink or similar that loads early you could do something like this:

var editRequireUrlInterval = setInterval(function() {
        if(typeof __onePageContext === "object") {
            __onePageContext.requireJSPath =  "http://spoprod-a.akamaihd.net/files/odsp-next-prod_ship-2017-08-04-sts_20170815.001/require-951f856e.js";
            clearInterval(editRequireUrlInterval );
        }
    }, 100);

That should be the previous version of requirejs

[BigEaseGueldi]

Some days before a go-live and I see people rebuilding Office UI Fabric React components in plain vanilla React ;-) Because:

• they are not sure that the team building the next require.js version even knows about this problem (@kristoferbrown - some kind of "working on it"/ "timeline"/ ... would really be nice - we don't need a fix tomorrow, but knowing that things should work again next week would definitely help)
• they don't want to use the hack above (a newer version of require.js might actually fix something/ performance?/ when will we know when it starts working again?/ ...)
• they are not sure whether you should rely on style injection which obviously can be switched off completely from outside.

I think it's these kind of bugs that don't help Office UI Fabric gaining even more traction. As I'm definitely a supporter of it I'd like to ask you for some clarification to smooth some ruffled feelings ;-)

Thanks for your help!

[Jahnp]

Sorry for the hassle and delay here! This looks like more of an issue with SPFx than with Fabric directly, and most folks working on Fabric probably won't have a lot of the context on the particulars of SPFx. I'll try to pull some folks in who'd be better-equipped to help.

[BigEaseGueldi]

I should have mentioned that in our case the Web Parts built with SPFx are not affected by this issue.

But if we are loading Office UI React components via Custom User Actions, script sections in page layouts, script editor web parts,... the styles are not loaded correctly.

Due to the different dependencies we have a strict separation between SPFx and other projects. So I don't think it has to do something with the SPFx, unless this team is responsible for the require.js...

[olemp]

It's not related to SPFx for us.

[mlp73]

We experience exactly the same here.
No SPFx but a script section is calling the components.

[dzearing]

This is not Fabric related, and not even require.js. I'm nearly certain this is SharePoint classic pages clearing css styling out because of a performance optimization in listviewdataprefetch.

Also it doesn't help that we don't have a clear repro. On a classic test page we have, webparts render fine, so there is some combination of things which is causing this. If someone has a repro url that we can access, that would be very handy.

@jijizz Can you please help investigate this? We should not be clearing out styling and I am wondering if this has anything to do with deferred styling, theming, or something unexpected.

[phettz]

Really, that's a bold statement, or you correct, I just hope you are correct

[olemp]

@dzearing I have a repro url. Send me an email?

[manishgarg1]

Hi @BigEaseGueldi, @olemp , @mlp73, @phettz ,

Is there a shareable to repro to this problem. A link to a page where we can see the broken scenario and an explanation of what is broken on that page.

regards

[dzearing]

Got a dev investigating; we're trying to validate what specific code is causing this. My suspicion is that it's related to the bundle, which require.js is loading, is calling this:

https://github.com/Microsoft/web-build-tools/blob/2a3f3891110071fce7cdd715cb8ac8a4119f2b0d/libraries/load-themed-styles/src/index.ts#L264

[dzearing]

Good news, we have confirmed my earlier suspicions. There is a performance optimization in the classic page code which is causing this as a side effect. The optimization is behind a flight. To validate this, @olemp your tenant was opted out of the optimization and we've confirmed it's now working.

We're evaluating if we should turn this flight off for all tenants (which could negatively impact performance for tenants without this case), or if we can roll out a fix to special case the optimization for classic pages that don't render modern webparts. This will be resolved one way or another shortly.

[dzearing]

The flight is now off for everyone. @BigEaseGueldi , @olemp, @phettz, @mlp73 can you please check if it's resolved for you?

[olemp]

Looks like it's working here now @dzearing, in several tenants actually. Good stuff!

[mlp73]

Great work and in pretty short time. It's good for us here as well. Thanks!

[BigEaseGueldi]

And finally the one who brought the trouble was also able to test.

-> works like a charm on different tenants.

Thanks for fixing this really quick! Having this today and not tomorrow made quite a difference for us!

[dzearing]

Happy to help! :)

[olemp]

@dzearing Has there been any changes to this lately? The issue is back, but not as frequently as before. 2-3 og 10 page loads approx.