SPFx v1.4.1 sp-office-ui-fabric-core styles not rendered/loaded

[cperson]

Category

• [x ] Question
• [ ] Typo
• [x ] Bug
• [ ] Additional article idea

Expected or Desired Behavior

The following classes referenced in an SPFx 1.4.1 solution would render appropriately : ms-Grid-col ms-sm3 ms-md3

Observed Behavior

Styles are not rendered based on classname.

This is happening as of 11/15/2019 at 2:00pm CST.

Steps to Reproduce

Create an SPFx v1.4.1 solution

Add the following line to you .scss: @import '~@microsoft/sp-office-ui-fabric-core/dist/sass/SPFabricCore.scss';

Add any className from UI Fabric (i.e. ms-Grid-col)

Deploy solution and observe css is not rendered.

QUESTION: Would it be possible to provide reference of CDN paths as it relates to SPFx and Office UI Fabric resources, or otherwise elaborate on how the styles are added to the markup?

We are attempting to root cause this issue with no luck, and the best reference we can find refers to Icons specifically. It would be nice to have docs regarding styles as well: https://github.com/OfficeDev/office-ui-fabric-react/wiki/using-icons

[msft-github-bot]

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

[Dangerous-Mind]

Same problem started two hours ago on one my my tenants on all my apps. On another tenant based on another continent they are still working fine for now. Spfx versions from 1.4.1 to 1.9.1.

[mmohamedbasith]

Slowly all tenants start seeing this issue. Root cause: old spfx solution having office fabric classes written directly in html markup.
Refer https://docs.microsoft.com/en-us/sharepoint/dev/spfx/office-ui-fabric-integration We can resolve this by rewriting the code to follow mixin systax for office fabric classes.

However it unfair to ask developers to rewrite previously working code which was written year ago and ask them now to rebuild the code all of sudden. So please provide support for 'global css syntax' for old version of code. Impose any new rule only for lastest version of the spfx solution

[patmill]

Digging into this. Is it possible to give some more info on tracking this down. Are there errors in the console? Are specific files not getting downloaded (check the network tab for 404s)? Do you have a small example of code that shows the issue?

[Dangerous-Mind]

My African tenant is back to normal. The European is still without css. No 403 error.

@patmill Some people usually use the ClassName= {"ms-Grid-col ms-sm12 ms-lg6"} syntax instead of doing include in scss and then applying it on the elements because is simpler and people don't have to load more css on to the page. Now Microsoft removed that css.

Ex: On the African Server they have: .ms-SPLegacyFabricBlock .ms-lg6 { width: 50%; } On the European server there is no definition on this class.

[mmohamedbasith]

@patmill Please let me know if you require any further information apart from @Dangerous-Mind given. Looking for a Quick resolution since most of these spfx solution will be on Production

[KevinTCoughlin]

@mmohamedbasith @Dangerous-Mind can you provide CDN URLs which are not serving the scoped selectors e.g. .ms-lg6 NOT .ms-SPLegacyFabricBlock .ms-lg6. That is unexpected; all CDNs should be serving scoped styles e.g. .ms-SPLegacyFabricBlock .ms-lg6.

Also, what does running the following JavaScript code on the impacted page(s) return:

document.querySelectorAll('.ms-SPLegacyFabricBlock')

The above should return a NodeList with length > 0. Those DOM Nodes should wrap the SPFx solutions so the scoped styles are applied.

The Fabric styles are scoped to the above .ms-SPLegacyFabricBlock selector.

If the CDN is serving the scoped styles as expected, then can you try a mitigation of appending the following className .ms-SPLegacyFabricBlock to your solution's root DOM Node?

[KevinTCoughlin]

Does anyone have an isolated SPFx 1.4.1 solution repro to expedite resolution?

[mmohamedbasith]

@KevinTCoughlin document.querySelectorAll('.ms-SPLegacyFabricBlock') gives zero nodes. However couple of hours ago i did saw SPFX webparts are wrapped with class 'ms-SPLegacyFabricBlock', not now.

No Apparent error in console. So I cannot find what is the CDN url missing .

[KevinTCoughlin]

@KevinTCoughlin document.querySelectorAll('.ms-SPLegacyFabricBlock') gives zero nodes. However couple of hours ago i did saw SPFX webparts are wrapped with class 'ms-SPLegacyFabricBlock', not now.

No Apparent error in console. So I cannot find what is the CDN url missing .

Is the content cached? SPFx solutions in latest release should be wrapped in the above selector as you saw a few hours ago.

Does manually appending .ms-SPLegacyFabricBlock to the DOM Node containing the SPFx solution mitigate the styling issue?

[mmohamedbasith]

.ms-SPLegacyFabricBlock

Yes manually appending class 'ms-SPLegacyFabricBlock' from developer tools, render fabric css properly.

However what i remember couple of hours ago was , i saw the class 'ms-SPLegacyFabricBlock' in webpart but the css not applied. Now i dont see the class 'ms-SPLegacyFabricBlock' in html And Contents are not cached . i removed all the cache and checked . still dont find the class.

[KevinTCoughlin]

I believe the following SPFx 1.4.1 WebPart sample solution exhibits the above mentioned problem: https://github.com/KevinTCoughlin/spfx-fabric-icons/blob/309ab6fafc381698d488fc021b7480dae8587026/src/webparts/helloWorld/HelloWorldWebPart.ts#L31

Is the above linked usage of Fabric Icon classNames similar to what is in-use in the regressed SPFx solutions?

[mmohamedbasith]

I believe the following SPFx 1.4.1 WebPart sample solution exhibits the above mentioned problem: https://github.com/KevinTCoughlin/spfx-fabric-icons/blob/309ab6fafc381698d488fc021b7480dae8587026/src/webparts/helloWorld/HelloWorldWebPart.ts#L31

Is the above linked usage of Fabric Icon classNames similar to what is in-use in the regressed SPFx solutions?

Yeah similar type, but can try below html with office fabric classes directly written in html

div className="ms-Grid" dir="ltr"> div class="ms-Grid-row"> div className="ms-Grid-col ms-sm6 ms-md4 ms-lg2">A

[Dangerous-Mind]

Comparing the two tenants. The Working one has the ms-SPLegacyFabricBlock class. I have the same problem in all SPFx versions. So it's not a SPFx version issue.

European Tenant (Not working): /<div class="Canvas-slideUpIn" data-sp-feature-tag="SupportStatisticsWebPart web part (Support Statistics)" data-sp-feature-instance-id="6948c5bd-c3ac-424e-b7bb-ad0f581dca1c" style="opacity: 0;">/<div style="width: 100%;">

African Tenant (Working) /<div class="Canvas-slideUpIn" data-sp-feature-tag="EnergyManagementWebPart web part (Energy Management)" data-sp-feature-instance-id="bfe68df2-2d24-4430-ae4e-75848f32b8b6" style="opacity: 0;"> /<div style="width: 100%;" class="ms-SPLegacyFabricBlock">

If I add the class to the non working tenant it will display correctly.

[mmohamedbasith]

Comparing the two tenants. The Working one has the ms-SPLegacyFabricBlock class. I have the same problem in all SPFx versions. So it's not a SPFx version issue.

European Tenant (Not working): /<div class="Canvas-slideUpIn" data-sp-feature-tag="SupportStatisticsWebPart web part (Support Statistics)" data-sp-feature-instance-id="6948c5bd-c3ac-424e-b7bb-ad0f581dca1c" style="opacity: 0;">/<div style="width: 100%;">

African Tenant (Working) /<div class="Canvas-slideUpIn" data-sp-feature-tag="EnergyManagementWebPart web part (Energy Management)" data-sp-feature-instance-id="bfe68df2-2d24-4430-ae4e-75848f32b8b6" style="opacity: 0;"> /<div style="width: 100%;" class="ms-SPLegacyFabricBlock">

If I add the class to the non working tenant it will display correctly.

Yeah. All tenant spfx with fabric following 'global css syntax' will have this issue. If MS can brought in the class 'ms-SPLegacyFabricBlock' in all tenant, it would solve the problem.

Anyhow latest spfx version 1.8.2,1.9.1 does not support global style css by default. Mostly the people follow mixins.so support is required for old versions spfx where css classes can be written in html itself.

[KevinTCoughlin]

We've tested a fix which resolves the issue we were seeing above. We'll be rolling it out now thru tomorrow.

[mmohamedbasith]

@KevinTCoughlin . Much appreciated for the swift response 👍

[ebouman]

Thanks for fixing this this fast! This makes a couple of our customers very happy.

[GnosisCode]

Our quick and dirty trick was to include these styles manually via the header extention; until this issues is fixed.

https://static2.sharepointonline.com/files/fabric/office-ui-fabric-js/1.4.0/css/fabric.min.css

[makafsal]

Currently, the fabric grid CSS file is not loading. As a quick fix, we can load it in our solution. Create .scss file you can name it as "global.scss" (just a name) and import the mixins and variables for the grid system.

:global() {
  @import "~office-ui-fabric-react/dist/sass/mixins/Grid.Mixins";
  @import "~office-ui-fabric-react/dist/sass/mixins/General.Mixins";
  @import "~office-ui-fabric-react/dist/sass/mixins/Directionality.Mixins";
  @import "~office-ui-fabric-react/dist/sass/mixins/Responsive.Mixins";

  @import "~office-ui-fabric-react/dist/sass/variables/Responsive.Variables";

  @import "~office-ui-fabric-react/dist/sass/_Grid.scss";
  @import "~office-ui-fabric-react/dist/sass/_Responsive.scss";
}

Then import this file in your web part file

import '../shared/theme/global.scss';

Now you can use ms-* classes. For eg:

<div className={`ms-Grid-col ms-xxxl12 ms-xxl12 ms-xl12 ms-lg12 ms-md12 ms-sm12`}>
    12 column
</div>

Note: I'm using SPFx & React.

[Dangerous-Mind]

We can also inject the missing class using a global SPFx extension. That will fix all the apps at the same time.

Something like:

$( '.ControlZone-control' ).each( function () {
    var zoneChild = $(this).children().children();
    zoneChild.addClass('ms-SPLegacyFabricBlock');
});

[VesaJuvonen]

Fix is now at 50% worldwide and is visible in the fixed tenants after hard reset of the browser cache (Ctrl+F5). If there are any updates on the impacted environments after this, please do report, so that we can detect if the correct fix operations were applied.

[NickSevens]

We see this working on multiple tenants already. Is there any way we can track if the fix has been applied? (version/patch number, ...?)

[KevinTCoughlin]

We see this working on multiple tenants already. Is there any way we can track if the fix has been applied? (version/patch number, ...?)

"View page source" and grep for "buildNumber", the build containing the fix contains 2019-11-08.018 or greater.

[PankajKTSPFX]

Looks like issue not yet resolved I didn't see any changes .

I see "buildNumber" : "sp-client-prod_2019-11-08.018" in view page source.

[ravick4u]

We see build number "sp-client-prod_2019-10-18.028" where the issue is fixed. Other tenants where the issue is not fixed have "sp-client-prod_2019-11-08.018"

[jtrejoslogic]

We see this working on multiple tenants already. Is there any way we can track if the fix has been applied? (version/patch number, ...?)

"View page source" and grep for "buildNumber", the build containing the fix contains 2019-11-08.018 or greater.

We see build number "buildNumber" : "sp-client-prod_2019-11-08.018", and the issue is not fixed.

[rmbw74]

We are also seeing build number "2019-11-08.018" and the issue is still present

[jtrejoslogic]

We see build number "sp-client-prod_2019-10-18.028" where the issue is fixed. Other tenants where the issue is not fixed have "sp-client-prod_2019-11-08.018"

Yes, we see a tenant with "buildNumber" : "sp-client-prod_2019-10-18.028", and the issue is fixed. But others with "buildNumber" :"sp-client-prod_2019-11-08.018" where the issue is not fixed.

[cryongen]

import '../shared/theme/global.scss';

I used it as temporaly workarround and works great with columns, however with text aligns not working :(

ms-textAlignCenter ms-textAlignRight

[Dangerous-Mind]

"buildNumber" : "sp-client-prod_2019-11-08.018"

Ok if I go directly to the page or from a list view to the web part using a link. If I'm on a page and click on a link to the web part the problem still happens. If I make F5 the page is displayed correctly.

I had the same problem when injecting the code on the extension. Not all scripts run when jumping from page to page.

[westleyMS]

Try to refresh the page you are navigating from (ctrl+F5) so the dynamic page load will get the new library before you navigate to the webpart page.

[Dangerous-Mind]

@westleyMS Not working.

When you jump between pages there is no complete refresh to the new page. And the script is not activated on the second page. That makes the class appear on the first page and not on the second one.

@KevinTCoughlin @VesaJuvonen Can you please check? Thanks

[westleyMS]

Moving between pages that are modern pages is a dynamic page load which means that the page doesn't get a load event. Webparts and extensions in SPFx must register for the navigation event, and if you didn't, then your component will not handle the navigation correctly, but this is not related to the issue at hand with office react fabric. This is how you get the navigation event- this.context.application.navigatedEvent.add(this, () => { // update your control })

This will fire on the dynamic page loading between modern pages. More on this here- https://github.com/SharePoint/sp-dev-docs/issues/1971

[jtrejoslogic]

Thanks, the issue is fixed. Now we have the "buildNumber" : "sp-client-prod_2019-10-18.028" and its all ok.

[Dangerous-Mind]

Moving between pages that are modern pages is a dynamic page load which means that the page doesn't get a load event. Webparts and extensions in SPFx must register for the navigation event, and if you didn't, then your component will not handle the navigation correctly, but this is not related to the issue at hand with office react fabric. This is how you get the navigation event- this.context.application.navigatedEvent.add(this, () => { // update your control })

This will fire on the dynamic page loading between modern pages. More on this here-

1971

I think you are missing the point. The fix made by Microsoft was not doing that event you mentioned. Wen we load the page it loads the fix. But navigating to a new page didn't load the fix. I had that same problem on one of my extensions months ago because I had forgot to add the event.

Thanks, the issue is fixed. Now we have the "buildNumber" : "sp-client-prod_2019-10-18.028" and its all ok.

Confirmed. It's working fine now. :)

[rmbw74]

We are seeing mixed results. Our build number remains unchanged, we are at sp-client-prod_2019-11-08.018, our layout issues seem to be resolved, however we are seeing outlining around office fabric ui buttons that did not have that before. most notably the close button on the fabric panel now has a black border around it.

[KevinTCoughlin]

We are seeing mixed results. Our build number remains unchanged, we are at sp-client-prod_2019-11-08.018, our layout issues seem to be resolved, however we are seeing outlining around office fabric ui buttons that did not have that before. most notably the close button on the fabric panel now has a black border around it.

@rmbw74, can you share a code sample or the CSS output from DevTools that shows us where that black border is coming from so we can triage and address?

An SPFx solution as a repro would be most helpful, but we can put one together if we know answers to the above.

[rmbw74]

Here is the markup for the panel close button.

<button type="button" class="ms-Panel-closeButton ms-PanelAction-close ms-Button ms-Button--icon css-709" data-is-visible="true" aria-label="Close" data-is-focusable="true" style=" border-color: red; "><div class="ms-Button-flexContainer css-700"><i role="presentation" aria-hidden="true" data-icon-name="Cancel" class="ms-Icon css-173 root-333 ms-Button-icon css-710"></i></div></button>

On the button element - the css-709 class which is dynamically created has a border width style and color in the CSS.

[Dangerous-Mind]

I also have some strange default buttons with white letters on a almost white background in a Modal element:

TypeScript <DefaultButton primary={true} onClick={this.SaveEditItem.bind(this)} text="Save" />

html:

<button type="button" class="ms-Button ms-Button--primary root-582" data-is-focusable="true" >
 <span class="ms-Button-flexContainer flexContainer-178" data-automationid="splitbuttonprimary">
  <span class="ms-Button-textContainer textContainer-179"><span class="ms-Button-label label-186" id="id__339">Save</span>
 </span>
  </span>
</button>

css:

`.root-582 {
    position: relative;
    font-family: "Segoe UI", "Segoe UI Web (West European)", "Segoe UI", -apple-system, BlinkMacSystemFont, Roboto, "Helvetica Neue", sans-serif;
    -webkit-font-smoothing: antialiased;
    font-size: 14px;
    font-weight: 400;
    box-sizing: border-box;
    display: inline-block;
    text-align: center;
    cursor: pointer;
    vertical-align: top;
    padding-top: 0px;
    padding-right: 16px;
    padding-bottom: 0px;
    padding-left: 16px;
    min-width: 80px;
    height: 32px;
    background-color: rgb(244, 244, 244);
    color: rgb(255, 255, 255);
    user-select: none;
    outline: transparent;
    border-width: 1px;
    border-style: solid;
    border-color: transparent;
    border-image: initial;
    text-decoration: none;
    border-radius: 0px;
}`

[Dangerous-Mind]

The culprit is the .root-xxx that overrides the color on the used class (theme primary color).

Correction: The root is not getting the theme color to the background of the button. It is supposed to override the text color. My mistake :)

[PankajKTSPFX]

Our build number changed again and back to previous stage we are seeing sp-client-prod_2019-11-08.018 ms-grid-row Grid layout issue resolved but buttons and drop down and people picker controls not rendering as expected.

[jtrejoslogic]

We Have now "buildNumber" : "sp-client-prod_2019-11-08.018" and same error with button class.

[mschaefer85]

"buildNumber" : "sp-client-prod_2019-11-08.021"

Still experiencing issues with columns.

Edit: Yesterday, everything seemed to be back to normal. Issues started again today.

[PankajKTSPFX]

"buildNumber" : "sp-client-prod_2019-11-08.021" layout issue started again this is very frustrating these changes making our existing application unstable.

[mmohamedbasith]

I hope Microsoft is having QA Testing team who are testing the tenants in multiple geography and existing SPFX solutions before pushing any new changes. Bugs are very obvious to our eyes.

[MartinsGrube]

I have also observed that Microsoft "style fix" has been changed.

Now (2019-11-20) it only works for the SharePoint Framework version 1.6. However, it does not work for versions 1.8 and 1.9 (it was working on 2019-11-19 after MS pushed fixes).

Note that I am referring to the versions 1.6, 1.8 and 1.9 as I have web parts in them I can quickly test in.

Here is the difference I see between yesterday’s 2019-11-19 and today’s 2019-11-20 behaviour:

• Yesterday the class “ms-SPLegacyFabricBlock” was not added to any web part versions. However, it worked for all versions as the dependency for Office UI Fabric styles to be used “under” element with the class “ms-SPLegacyFabricBlock” was removed.

• Today:

  • The dependancy for Office UI Fabric styles to be “under” element with the class “ms-SPLegacyFabricBlock” is back.
  • The class “ms-SPLegacyFabricBlock” is added for 1.6 web parts. So they work as expected.
  • The class “ms-SPLegacyFabricBlock” is not added for 1.8 and 1.9 web parts. So they do not work as expected.

Info about build numbers:

• Yesterday I had "sp-client-prod_2019-11-08.018", but note that it was like this both before and after web part designs started to work as expected.
• Today I had the same "sp-client-prod_2019-11-08.018" in the morning when the issue reappeared for versions 1.8 and 1.9. Now it has changed to "sp-client-prod_2019-11-08.021".

Perhaps build numbers are somehow cached or fixes are done outside of the build scopes as behaviour does not seem to follow builds directly. But anyway - this info might be useful.

Can you please continue work on this issue?

[rmbw74]

we are now on "sp-client-prod_2019-10-18.028" and it looks like the strange outlining behavior on the button classes has stopped. On a maybe related note, i noticed the styling of the Debug Dialog has reverted back to its original look.

[rmbw74]

Looks like I spoke too soon, now we are back to sp-client-prod_2019-11-08.021 and things are broken again! so frustrating.

[KevinTCoughlin]

We continue to actively work on this issue. The more information provided to help the team assess the regressed scenarios the sooner we can reach a resolution.

For context, Office UI Fabric has been updated on the host page to version 7. Unfortunately, Office UI Fabric 7 contains style regressions and is impacting SPFx solutions downstream as a side-effect; some of those regressions are mentioned above e.g. button outline.

@mschaefer85 by "columns" are you referencing .ms-Grid classes? What SPFx version is your solution 1.4.x .. 1.9.x?

@PankajKTSPFX same question for you regarding your reference to "layout" and which version of SPFx solution are impacted. Or are is the regression scoped to https://github.com/SharePoint/sp-dev-docs/issues/4911#issuecomment-555613444?