SharePoint / sp-dev-docs

SharePoint & Viva Connections Developer Documentation
https://docs.microsoft.com/en-us/sharepoint/dev/
Creative Commons Attribution 4.0 International
1.23k stars 991 forks source link

SPFx webpart icons being replaced by default office fabric icon #9751

Open ruiafonso8443 opened 2 weeks ago

ruiafonso8443 commented 2 weeks ago

Target SharePoint environment

SharePoint Online

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

💥 SharePoint Framework

Developer environment

None

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

Additional environment details

No response

Describe the bug / error

For the last two months, the SPFx web part icon images are not being rendered. By default, the property officeFabricIconFontName is being defined as "Page" automatically upon generating the .sppkg file of said web part. With this, the value defined in the iconImageUrl of the preconfiguredEntries is being overridden by the Fabric Icon and therefore being ignored in SharePoint. Below, you can see the resulting issue: image

As a workaround, the property officeFabricIconFontName can be defined in the preconfiguredEntries as an empty string to give priority to the defined iconImageUrl. However, this isn't a valid or acceptable solution since it requires the modification of this property in all existing web parts.

image

The main question is the reason why the officeFabricIconFontName all of a sudden has been given priority instead of the iconImageUrl?

Steps to reproduce

  1. Deploy a web part to a tenant.
  2. Open the toolbox to add a new web part.
  3. Verify the defined iconImageUrl is missing and was replaced by the Office Fabric Icon 'Page'.

Expected behavior

The expected result was the intended image defined in the iconImageUrl to appear in the toolbox.

mkm17 commented 2 weeks ago

Hi @ruiafonso8443, according to the documentation and this section, when both the officeFabricIconFontName and the iconImageUrl properties are specified, the icon specified in the officeFabricIconFontName is used.

If the previous behavior was different, then it looks like, unfortunately for your case, it is fixed now.