Sp-dev-docs: 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?

[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?

[mschaefer85]

@KevinTCoughlin Thanks for the update, Kevin. Yes, by "columns" I'm referring to issues with ".ms-Grid" (for example).

The solution is SPFx v. 1.4.

[unowiz]

I have this same issue on one of 4 tenants (PROD being the one affected). I have a spfx webpart being used in a group of hub connected sites. I have used office ui fabric DefaultButtons that has the border added now and wasn't there until a week back. PrimaryButton doesn't seem to be affected.

My webpart is on 1.6 and I realise that in the package.json, I haven't added office-ui-fabric-react as dependency but I have my react component using the DefaultButton.
import { DefaultButton } from 'office-ui-fabric-react/lib/components/Button/DefaultButton/DefaultButton';
The site collections are communication site and are hub connected. In any case, this worked till last week and still works well with no borders in other 3 tenants

In the same PROD tenant, I have a different webpart(in a different site collection) that is based on Spfx 1.8.2 and has dependency office-ui-fabric-react: 6.143.0 explicitly mentioned in the package.json. The site collection is communication site and is not hub or part of any. I don't see the unwanted border to DefaultButton here. The border is transparent(1px solid transparent).

[PankajKTSPFX]

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 #4911 (comment)?

@KevinTCoughlin thanks for the response, we are using 1.5.1 SPFX version and I am referring to issue with style button,people picker control, Grid layout.

[patmill]

OK, latest update on this. We're rolling back the entire build. The only downside to this is that it's harder to know what the issues are. So, if you had issues, if possible, can you post what your code looked like? What spfx version, if you had the LegacyCSS property set in your manifest, etc.

The hope is that there will be some broad changes that can be made that will solve the issues, and that it won't require a succession of incremental fixes.

Again - I apologize for this. I feel like we burned through a chunk of good will, and hope to get it back.

[KevinTCoughlin]

@ralucao, do you have the following specified in your WebPart's manifest:

  "loadLegacyFabricCss": true,

For SPFx solution versions >= 1.8.2 we require the above flag be set to load global Fabric core styles referenced via CSS like you've shared above e.g. <div className="ms-Grid-col ms-lg2" />.

We recommend for solutions > 1.8.2 that the following styling strategy be used: https://docs.microsoft.com/en-us/sharepoint/dev/spfx/office-ui-fabric-integration#updated-way-to-use-icons-after-spfx-182

[KevinTCoughlin]

🚨🚨🚨 Responses needed 🚨🚨🚨

For those who had their existing solutions regress related to Fabric core styling, .ms-Icon, .ms-Grid, etc., we need answers to the following:

1) What exact version of SPFx is the solution? 1.4.x, 1.8.x, 1.9.x?
2) Does the solution reference Fabric core global styles via CSS in the DOM e.g. <div className={'ms-Grid-Col ms-lg6'} />.
3) Do you specify loadLegacyFabricCss: true in the manifest?

Thanks in advance!

[PankajKTSPFX]

thanks for rolling back the changes looks like style is loading properly with "buildNumber" : "sp-client-prod_2019-10-18.028". please do not push any new changes without complete testing.
 

[KevinTCoughlin]

thanks for rolling back the changes looks like style is loading properly with "buildNumber" : "sp-client-prod_2019-10-18.028". please do not push any new changes without complete testing.

@PankajKTSPFX can you please answer questions #2 and #3 in https://github.com/SharePoint/sp-dev-docs/issues/4911#issuecomment-556907698? Thanks. I already have your SPFx version as 1.5.1.

Also are the outlines you see in Picker and Button in first-party or third-party controls?

[KevinTCoughlin]

Thanks for your response @mmohamedbasith; they help us verify our hypothesis. Regarding the inherited styles:

Fabric team made a number of breaking style changes in their latest major release which are being inherited by WebPart controls. We are looking into a solution for that separately.

[mschaefer85]

🚨🚨🚨 Responses needed 🚨🚨🚨

For those who had their existing solutions regress related to Fabric core styling, .ms-Icon, .ms-Grid, etc., we need answers to the following:

1. What exact version of SPFx is the solution? 1.4.x, 1.8.x, 1.9.x?
2. Does the solution reference Fabric core global styles via CSS in the DOM e.g. <div className={'ms-Grid-Col ms-lg6'} />.
3. Do you specify loadLegacyFabricCss: true in the manifest?

Thanks in advance!

1. 1.4
2. Yes
3. No

[KevinTCoughlin]

🚨🚨🚨 Responses needed 🚨🚨🚨
For those who had their existing solutions regress related to Fabric core styling, .ms-Icon, .ms-Grid, etc., we need answers to the following:

1. What exact version of SPFx is the solution? 1.4.x, 1.8.x, 1.9.x?
2. Does the solution reference Fabric core global styles via CSS in the DOM e.g. <div className={'ms-Grid-Col ms-lg6'} />.
3. Do you specify loadLegacyFabricCss: true in the manifest?

Thanks in advance!

1. 1.4
2. Yes
3. No

Hrmm that SPFx version 1.4.x should not have been impacted. I tested .ms-Grid in isolation using 1.4.1 and it rendered properly. Here was my branch: https://github.com/KevinTCoughlin/spfx-fabric-icons/compare/keco/grid-legacy?expand=1.

@mschaefer85, may I request a repro from you either by forking the above or creating your own? The portion of code containing the styles which regressed should be sufficient.

[mmohamedbasith]

🚨🚨🚨 Responses needed 🚨🚨🚨
For those who had their existing solutions regress related to Fabric core styling, .ms-Icon, .ms-Grid, etc., we need answers to the following:

1. What exact version of SPFx is the solution? 1.4.x, 1.8.x, 1.9.x?
2. Does the solution reference Fabric core global styles via CSS in the DOM e.g. <div className={'ms-Grid-Col ms-lg6'} />.
3. Do you specify loadLegacyFabricCss: true in the manifest?

Thanks in advance!

1. 1.4
2. Yes
3. No

Hrmm that SPFx version 1.4.x should not have been impacted. I tested .ms-Grid in isolation using 1.4.1 and it rendered properly. Here was my branch: https://github.com/KevinTCoughlin/spfx-fabric-icons/compare/keco/grid-legacy?expand=1.

@mschaefer85, may I request a repro from you either by forking the above or creating your own?

@KevinTCoughlin Are you sure ,your code was working on 16th Nov19 ? Bcoz it does not work for me (Similar code you used).I think you were able to replicate the issue on 17th Nov'19 on SPFX 1.4.1.
After your first fix release , it layout issue got resolved (in spfx 1.4.1) , But only the border/Outline issue remained .
Couple of days later , Again i started to see partial layout issues in SPFX 1.4.1

[NickSevens]

🚨🚨🚨 Responses needed 🚨🚨🚨

For those who had their existing solutions regress related to Fabric core styling, .ms-Icon, .ms-Grid, etc., we need answers to the following:

1. What exact version of SPFx is the solution? 1.4.x, 1.8.x, 1.9.x?
2. Does the solution reference Fabric core global styles via CSS in the DOM e.g. <div className={'ms-Grid-Col ms-lg6'} />.
3. Do you specify loadLegacyFabricCss: true in the manifest?

Thanks in advance!

1. We have solution ranging from v1.7.0 to v1.9.1
2. Yes, exactly that.
3. No, there is no loadLegacyFabricCss: true in our manifest

[KevinTCoughlin]

🚨🚨🚨 Responses needed 🚨🚨🚨
For those who had their existing solutions regress related to Fabric core styling, .ms-Icon, .ms-Grid, etc., we need answers to the following:

1. What exact version of SPFx is the solution? 1.4.x, 1.8.x, 1.9.x?
2. Does the solution reference Fabric core global styles via CSS in the DOM e.g. <div className={'ms-Grid-Col ms-lg6'} />.
3. Do you specify loadLegacyFabricCss: true in the manifest?

Thanks in advance!

1. 1.4
2. Yes
3. No

Hrmm that SPFx version 1.4.x should not have been impacted. I tested .ms-Grid in isolation using 1.4.1 and it rendered properly. Here was my branch: KevinTCoughlin/spfx-fabric-icons@keco?expand=1 (compare).
@mschaefer85, may I request a repro from you either by forking the above or creating your own?

@KevinTCoughlin Are you sure ,your code was working on 16th Nov19 ? Bcoz it does not work for me (Similar code you used).I think you were able to replicate the issue on 17th Nov'19 on SPFX 1.4.1.
After your first fix release , it layout issue got resolved (in spfx 1.4.1) , But only the border/Outline issue remained .
Couple of days later , Again i started to see partial layout issues in SPFX 1.4.1

@mmohamedbasith we've confirmed what led to the Fabric core styles regression for SPFx solutions > 1.8 that do not specify the loadLegacyFabricCss manifest flag as true when present on a page without a WebPart which does request legacy Fabric CSS. The appropriate build was used to test internally.

Good call-out, we patched the original product bug for 1.4.x when multiple WebParts were present on the page and redeployed and rolled-back today AM. I'd like more samples to confirm the patched build fixed all < 1.8 solutions.

[MartinsGrube]

🚨🚨🚨 Responses needed 🚨🚨🚨

For those who had their existing solutions regress related to Fabric core styling, .ms-Icon, .ms-Grid, etc., we need answers to the following:

1. What exact version of SPFx is the solution? 1.4.x, 1.8.x, 1.9.x?
2. Does the solution reference Fabric core global styles via CSS in the DOM e.g. <div className={'ms-Grid-Col ms-lg6'} />.
3. Do you specify loadLegacyFabricCss: true in the manifest?

Thanks in advance!

Answers:

1. 1.6, 1.8, 1.9
2. Yes
3. No
   I understand that we need to set "loadLegacyFabricCss: true" for 1.8 and 1.9 versions.

Updates about current (2019-11-21) situation:

1. Build is "sp-client-prod_2019-11-08.028"
2. Behaviour is back to how it was on 2019-11-19: The class “ms-SPLegacyFabricBlock” is not added to any web part versions. However, it works for all versions as the dependency for Office UI Fabric styles to be used “under” element with the class “ms-SPLegacyFabricBlock” is removed.

Suggestion:

1. It would be good if information about "loadLegacyFabricCss: true" for versions >= 1.8.2 is added to https://docs.microsoft.com/en-us/sharepoint/dev/spfx/office-ui-fabric-integration

[mmohamedbasith]

🚨🚨🚨 Responses needed 🚨🚨🚨
For those who had their existing solutions regress related to Fabric core styling, .ms-Icon, .ms-Grid, etc., we need answers to the following:

1. What exact version of SPFx is the solution? 1.4.x, 1.8.x, 1.9.x?
2. Does the solution reference Fabric core global styles via CSS in the DOM e.g. <div className={'ms-Grid-Col ms-lg6'} />.
3. Do you specify loadLegacyFabricCss: true in the manifest?

Thanks in advance!

1. 1.4
2. Yes
3. No

Hrmm that SPFx version 1.4.x should not have been impacted. I tested .ms-Grid in isolation using 1.4.1 and it rendered properly. Here was my branch: KevinTCoughlin/spfx-fabric-icons@keco?expand=1 (compare).
@mschaefer85, may I request a repro from you either by forking the above or creating your own?

@KevinTCoughlin Are you sure ,your code was working on 16th Nov19 ? Bcoz it does not work for me (Similar code you used).I think you were able to replicate the issue on 17th Nov'19 on SPFX 1.4.1.
After your first fix release , it layout issue got resolved (in spfx 1.4.1) , But only the border/Outline issue remained .
Couple of days later , Again i started to see partial layout issues in SPFX 1.4.1

@mmohamedbasith we've confirmed what led to the Fabric core styles regression for SPFx solutions > 1.8 that do not specify the loadLegacyFabricCss manifest flag as true when present on a page without a WebPart which does request legacy Fabric CSS. The appropriate build was used to test internally.

Good call-out, we patched the original product bug for 1.4.x when multiple WebParts were present on the page and redeployed and rolled-back today AM. I'd like more samples to confirm the patched build fixed all < 1.8 solutions.

@KevinTCoughlin Hmmm. Its too Hard. Too many SPFX & fabric versions,scenarios to think of . My heart goes out to the guys you are really working hard to resolve this.

I would like to add one scenarios, Apart from my spfx 1.4.1 solution , i am working on another spfx 1.8.2 which does not faced any layout issue during the period . May be bcoz i used only mixins syntax (not any global css) and Also i havent used loadLegacyFabricCss: true in manifest.

[jtrejoslogic]

🚨🚨🚨 Responses needed 🚨🚨🚨

For those who had their existing solutions regress related to Fabric core styling, .ms-Icon, .ms-Grid, etc., we need answers to the following:

1. What exact version of SPFx is the solution? 1.4.x, 1.8.x, 1.9.x?
2. Does the solution reference Fabric core global styles via CSS in the DOM e.g. <div className={'ms-Grid-Col ms-lg6'} />.
3. Do you specify loadLegacyFabricCss: true in the manifest?

Thanks in advance!

1. 1.6
2. Yes
3. No

[ralucao]

@ralucao, do you have the following specified in your WebPart's manifest:

  "loadLegacyFabricCss": true,

For SPFx solution versions >= 1.8.2 we require the above flag be set to load global Fabric core styles referenced via CSS like you've shared above e.g. <div className="ms-Grid-col ms-lg2" />.

We recommend for solutions > 1.8.2 that the following styling strategy be used: https://docs.microsoft.com/en-us/sharepoint/dev/spfx/office-ui-fabric-integration#updated-way-to-use-icons-after-spfx-182

Hi Kevin,
We do not have the loadLegacyFabricCss property set in our solution. We will try that.Thanks

[mpowney]

For those who had their existing solutions regress related to Fabric core styling, .ms-Icon, .ms-Grid, etc., we need answers to the following:

1. What exact version of SPFx is the solution? 1.4.x, 1.8.x, 1.9.x?
2. Does the solution reference Fabric core global styles via CSS in the DOM e.g.
   .
3. Do you specify loadLegacyFabricCss: true in the manifest?

Question 1

• SPFx 1.4.1 unsure - Issue first noticed with a customers' solution on SPFx 1.4.1 - we didn't see it regress on this solution (though, it may have regressed without us noticing it)
• SPFx 1.8.2 unsure - Issue also noticed with a customers' solution on SPFx 1.8.2 - we implemented a work around which may have masked any subsequent regression
• SPFx 1.8.0 yes - Issue also noticed with a customers' solution on SPFx 1.8.0 - this solution fixed itself without intervention from us, and was then confirmed to have regressed this week, but is now showing icons as expected

Question 2

• SPFx 1.4.1 yes
• SPFx 1.8.2 yes
• SPFx 1.8.0 yes

Question 3

• SPFx 1.4.1 no
• SPFx 1.8.2 no
• SPFx 1.8.0 no
  (we weren't aware the loadLegacyFabricCss property exists!)

[Mag000]

1.8.1, upgraded in several steps from 1.5.1
Only through scss
No

[patmill]

We hope to be rolling a fix out soon (later today). In the meantime, here is a first draft of guidance around using the legacy fabric css files.

https://github.com/SharePoint/sp-dev-docs/wiki/Safely-using-legacy-Fabric-Styles

We'll update and post it to the official docs as well, but this gets it out to you sooner.

[NickSevens]

@patmill in the documentation you're pointing to the "solution manifest", whereas it should be the "webpart manifest".

For solutions using SPFx >= 1.8.2, ensure that the solution manifest demands legacy Fabric core styles be loaded onto the page. This is done by specifying loadLegacyFabricCss: true in the solution manifest.

[rmbw74]

we are having layout issues again.. looking at the page, we are seeing sp-client-prod_2019-11-08.025 as the buildNumber, we were on .028 when all was fixed. The solution we are having the issues with is a 1.4.1 solution

[carletto75]

Same Issue here.

[patmill]

@rmbw74, @carletto75 - How are you using the fabric styles? What kind of solution have you made(webpart? extension?) Where is the content rendering (in a webpart or placeholder div? In a div you add to the page manually?). Can you share your relevant package.json entries (PNP, fabric, ouifr, etc) and some sample code with what you are doing? Maybe a screenshot showing the issues?

Anything that can help us diagnose what is going on. Thanks.

[mmohamedbasith]

As of this moment , My SPFX 1.4.1 Solution working Fine.
Build Number i see is: "buildNumber" : "sp-client-prod_2019-11-08.025"

Last week i was having layout issue .Not Now.

[Dangerous-Mind]

The only thing that is not ok on my solutions are the default buttons with Primary option set to true that dont get the backgroud color from the site theme.

<DefaultButton primary={true} onClick={() => this.Submit()} >Submeter</DefaultButton>

.root-500 { 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: 2px; }

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

SPFx 1.8.2 and 1.9.1
"loadLegacyFabricCss": true

[patmill]

Thanks @Dangerous-Mind - and to confirm, you are using the DIVs provided by the framework?

[Dangerous-Mind]

Changed it to <PrimaryButton> and it works fine.

<PrimaryButton onClick={() => this.Submit(true)}>Submeter</PrimaryButton>

The button doesnt have any class defined by me. It should be working ok without my intervention.
If you are referring to the ms-SPLegacyFabricBlock. It's on the top before the webpart start.

[rmbw74]

@patmill

• we are using the classes directly, not via mixins in scss
• this is a spfx 1.4.1 webpart deployed to SPO
• this content is being rendered in a react component in a webpart
  Our main react component seems to be getting the ms-SPLegacyFabricBlock applied,
  but the components that exist on Fabric Panels do not.

package.json
{ "name": "launchpad", "version": "0.0.1", "private": true, "engines": { "node": ">=0.10.0" }, "scripts": { "build": "gulp bundle", "clean": "gulp clean", "test": "gulp test" }, "dependencies": { "@microsoft/applicationinsights-web": "^2.0.0-rc4", "@microsoft/sp-core-library": "~1.4.0", "@microsoft/sp-lodash-subset": "~1.4.0", "@microsoft/sp-office-ui-fabric-core": "~1.4.0", "@microsoft/sp-webpart-base": "~1.4.0", "@pnp/common": "^1.3.5", "@pnp/graph": "^1.3.5", "@pnp/logging": "^1.3.5", "@pnp/odata": "^1.3.5", "@pnp/polyfill-ie11": "^1.0.2", "@types/es6-promise": "0.0.33", "@types/react": "16.4.2", "@types/react-dom": "16.0.5", "@types/webpack-env": "1.13.1", "react": "16.3.2", "react-dom": "16.3.2", "react-sortable-hoc": "^1.9.1" }, "resolutions": { "@types/react": "16.4.2" }, "devDependencies": { "@microsoft/sp-build-web": "~1.4.1", "@microsoft/sp-module-interfaces": "~1.4.1", "@microsoft/sp-webpart-workbench": "~1.4.1", "gulp": "~3.9.1", "@types/chai": "3.4.34", "@types/mocha": "2.2.38", "ajv": "~5.2.2" } }

here is the markup at the start of our main component

and here is what that looks like (i've had to edit out some text for security)

Here is the markup for our fabric panel -

here is what that looks like (notice the layout is not following the grid, it should be the same as the main component)

If I append the legacyBlock class to the fabric panel it renders as expected

[KevinTCoughlin]

@rmbw74 thanks for the above; we are actively working on a mitigation for Fabric's Layer-based controls using a similar approach (appending the className .ms-SPLegacyFabricBlock).

Since _some_ Fabric components (those reliant on Fabric Layer) append to document.body, they are rendered outside of the legacy Fabric core scoped styles. The scoped Fabric core styles were introduced to mitigate Fabric 7's incompatibility with Fabric core.

We will report status here. Apologies for the breakage.

[NickSevens]

@rmbw74 @KevinTCoughlin we have indeed the same issue when rendering inside a Panel, since it's not rendering within a correctly styled container. Applying the same workaround as well...

[v-pajorg]

@KevinTCoughlin sent you a message in Teams

[carletto75]

Same Issue here.

I solved my issue by adding class="ms-SPLegacyFabricBlock", as suggested to me in issue #4919
Thank you

[aaronmi]

For those who had their existing solutions regress related to Fabric core styling, .ms-Icon, .ms-Grid, etc., we need answers to the following:

1. What exact version of SPFx is the solution? 1.4.x, 1.8.x, 1.9.x?
2. Does the solution reference Fabric core global styles via CSS in the DOM e.g. <div className={'ms-Grid-Col ms-lg6'} />.
3. Do you specify loadLegacyFabricCss: true in the manifest?

Thanks in advance!

For a customer with "buildNumber" : "sp-client-prod_2019-11-08.025"

1. 1.7.1 (webpart solution)
2. Yes
3. No

The solution renders inside the Panel component of the Office Fabric.

[OliverZeiser]

In my case we have updated our solution to use Fabric-UI-React 7 and, the fix you are doing with the ms-SPLegacyFabricBlock is actually really bad because there are some global styles that override the Fabric-UI-React styles of the components. One example of those global styles is .ms-SPLegacyFabricBlock .ms-Icon{}
I am undoing this right now in my application customizer via this:
this._topPlaceholder.domElement.className="";

I think you should only wrap our components with ms-SPLegacyFabricBlock when loadLegacyFabricCss: true is specified in the manifest.

We are on 1.9.1--plusbeta and are NOT specifying loadLegacyFabricCss:true

[patmill]

@OliverZeiser - you are 100% correct. The forcing of the legacy fabric block is a temporary measure to give people time to update their solutions. When we roll out support for fabric 7 (which we can't do because of the issue you mention) we will remove that 'fix'. OUIFR7 is not supported yet. We (I?) want to handle it differently than OUIFR6 was, with better support that doesn't rely on devs to include all the code in all their solutions. That will be a job for early next year though.

[OliverZeiser]

Thank you very much Pat for the quick and great (honest) response. Right now for us OUIFR7 is working just fine and it looks much more aligned to the current design changes (fluent..) that are rolling out to the tenants. Is it okay for us to keep setting ....domElement.className="" for our components to prevent the ms-SPLegacyFabricBlock css class for now or should we expect more changes like that in the near future and revert to OUIFR6?

[patmill]

That's should be OK. Let us know what other issues you run across.

[abhishek-raj]

@patmill I am also seeing the same regressions using DefaultButton with primary attribute set to true as @Dangerous-Mind. Using PrimaryButton solves this but there is some regression when using the button as a MenuButton.

I am using this code :

<PrimaryButton 
    menuProps={{
        shouldFocusOnMount: true,
        items: [
        {
            key: 'MenuItem1',
            name: 'Menu Item 1'
        },
        {
            key: 'MenuItem1',
            name: 'Menu Item 1'
        },
        ]
    }}
>
    Menu Button 2
</PrimaryButton>

When the menu is open the styles on the button seems to be broken.

Menu collapsed:

Menu expanded:

I had created a issue on office-ui-fabric-react also. Linking it here: https://github.com/OfficeDev/office-ui-fabric-react/issues/11356

[jpalo]

The surrounding .ms-SPLegacyFabricBlock DIV is also exploding width of the web part on classic pages with IE11. Had to clear the class like @OliverZeiser suggested.

[andrewconnell]

Seems like this was resolved...

[mmohamedbasith]

Seems like this was resolved...

I would disagree. Content in Office fabric panel/dialog is still having issues in SPFX1.4.1 . After waiting for long and no resolution found provided for that, everyone the might be forced to reworked the code to use mixins in scss which could resolve the CSS issues.

[msft-github-bot]

This issue has been automatically marked as stale because it has marked as requiring author feedback but has not had any activity for 7 days. It will be closed if no further activity occurs within the next 7 days of this comment. Please see our wiki for more information: Issue List Labels: Needs Author Feedback & Issue List: No response from the original issue author

[msft-github-bot]

Closing issue due to no response from the original author. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: No response from the original issue author