SPFx CommandSets and FieldCustomizer not working in new view UI

[florianwachter]

Target SharePoint environment

SharePoint Online

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

💥 SharePoint Framework

Developer environment

Windows

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

• [ ] 💥 Internet Explorer
• [X] 💥 Microsoft Edge
• [ ] 💥 Google Chrome
• [ ] 💥 FireFox
• [ ] 💥 Safari
• [ ] mobile (iOS/iPadOS)
• [ ] mobile (Android)
• [ ] not applicable
• [ ] other (enter in the "Additional environment details" area below)

Additional environment details

• Browser Version: Edge 121.0.2277.112
• SPFx version: 1.18.1
• Node.js version v18.18.2

Describe the bug / error

A few hours ago, the views in one of our lists changed to the new Lists UI and all the CommandSets and FieldCustomizer that are registered on this list are gone. Here is a screenshot: Usually we have a few commands visible if one or multiple items are selected. Also some columns have FieldCustomizers registered to change the rendering, but they all show the default way. Looks like all the customizations are gone. Looks like ApplicationCustomizers are working.

Steps to reproduce

1. Add a SharePoint Framework app to a SharePoint website that has command sets registered on lists
2. Make sure the list already has the new experience with the views showing up as tabs (see the screenshot above). Our tenant is set to Target Release, but some views still show the old experience (which is working fine).
3. The command sets will not show in the new UI
4. The same happens for FieldExtensions

Expected behavior

CommandSets and FieldCustomizer should also show in the new UI.

[ghost]

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

[AJIXuMuK]

@florianwachter - thank you for submitting the issue! Unfortunately, I can't repro the issue - is it still happening for you?

Could you please a few things?

• are you seeing any error in the console?
• if you open Network tab in Dev Tools and refresh the page:
  • are you seeing request for https://res-1.cdn.office.net/files/sp-client/listview-host-assembly_en-us_<hash-code>.js?
  • if you open the aspx response and search for ClientSideComponentId - are you seeing your SPFx solution in there?

[florianwachter]

@AJIXuMuK - thanks for your assistance.

Please find my answers below:

1. No, I don't see any errors in the console related to this.
2. Yes, I see the request to the listview-host-assemly js and the entire URL is https://res-1.cdn.office.net/files/sp-client/listview-host-assembly_en-us_5061854e0c9eb8062748cd2905c95f86.js
3. Yes, I can see the commandSet componentIds in g_clientComponents and I can see the componentIds of the fieldcustomizers in window._spClientSideComponentIds.

I hope this helps. Please let me know if you need further details.

Thanks!

[florianwachter]

I have one more question regarding this issue. The message center entry MC709979 that announced this change mentiones that these improvements will NOT reach Lists that have been configured with SharePoint Framework extensions (see below).

"Users in affected tenants will see Lists feature updates as described in Microsoft Lists: Easier, Better, Faster, Stronger - Microsoft Community Hub when browsing to lists in SharePoint sites, the Lists progressive web app (PWA), and Lists in Teams. All Lists in SharePoint sites will maintain the SharePoint site's chrome, theming, and navigation. **These improvements will NOT reach Lists that have been configured with these features:

SharePoint Framework extensions** PowerApps forms Approvals The Playlist template"

Does anyone know what this means exactly? Does it mean if there is a commandset configured for the list, or any field with a fieldcustomizer registered, the list will remain in the old UI. At least for now.

@AJIXuMuK : You mentioned that you cannot repro the issue. Does it mean that you see the old list experience or that you have the new experience with your custom actions, etc.?

Thanks!

[AJIXuMuK]

The new experience should not appear if there are SPFx command sets or field customizers. And that is the behavior I'm observing. I believe you are in touch with the owning team to solve the issue as it seems to be scoped to some unique situations.

[florianwachter]

@AJIXuMuK - Thanks for your answer!

[henningeiben]

I can confirm, that I've been seeing the "new" Lists UX in SharePoint Lists as well ... and also for Lists that have SPFx Extensions deployed that provide custom commandsets and other customizations.

These commandsets are not visible any more and the customizations don't work as expected either. For example: I have a solution, which is supposed to open a panel from the right (as the add-new-item action would do from the commandbar). This is now opening a new tab with my page, instead of a panel. Just as one example.

I would argue, that this is a bug we're seing. This new UI is not yet ready for sites with SPFx extensions, but somehow this is being applied to these sites as well.

Also: not everyone on our tenant is receiving this experience. I have this behaviour, a colleague new room still has the "old" UX.

BTW: yes, my tenant is first-release 😉

[florianwachter]

@henningeiben - I am in contact with an engineer from the Lists/SharePoint team who is looking into this and I'll keep you posted about the result.

[AJIXuMuK]

@florianwachter please use this issue for the updates so the others could find the results too

[natalieethell]

Thank you for reporting! It looks like we have a bug specific to personal views. The workaround for now while we work on a fix would be to use a public view and not a personal view.

If that's not sufficient, please send me a message.

[henningeiben]

@natalieethell: I cannot confirm this. I also see this "new" list UX in public views!

At first I had the impression, that this UX would only show up when I'm accessing the allitems.aspx and I would still get the old UX when I'm accessing views by their aspx-pages (like archive.aspx). I figured when I'm accessing the archive-view (a public view an a list) using allitems.aspx?viewid=[id of the archive-view] this would trigger the new UX, while just archive.aspx would still show the old UX.

But that was on Wednesday. Since yesterday I'm getting the new UX on most lists/views (however - not on all of them!).

To make it even more confusing (if that is possible): today I get for some (public) views again the old UX, where I got Tuesday and Wednesday the new UX. 🤯

[smolattack]

@florianwachter please use this issue for the updates so the others could find the results too

I'm pretty sure it's not the job of your customers to let others know about your product's ongoing issue status. I know your answer will be that some other team @ Microsoft caused this issue so don't bother.

[VesaJuvonen]

Huge thanks everyone for your input on this. We do apologize the delay here and are currently actively looking on solving this issue.

We are also curious on understanding how widely this issue is visible worldwide, so if this is an active issue for you, please add a comment with small description, so that we can see the impact.

At the same time we are now actively working on solving this internally.

[juliemturner]

I can confirm that this is an issue still at least for command sets. If it's not supposed to be enabled if a command set/field customizer is present that is not happening in all cases, further, is it the intent that if you want to add a field customizer or command set later that it would revert? I have found that I'm able to fall back to "Standard Release" wait for the UI to switch back, add the field customizer... then if I switch back to "Targeted release for everyone" the command set doesn't show up but the console shows that it was loaded.

Standard Release

Targeted Release

[SPJS]

I have the same problem here with a command set extension that is targeting multiple list (using RegistrationId in elements.xml and ListTemplateId in ClientSideInstance.xml).

It looks like some lists created earlier stays in the "classic modern experience" and the command set extension is active, but if I create a new list it shows in the "Microsoft lists modern experience" and the command set is not loaded (the strings files from the solution is loaded, but not the script files).

I hope this can be resolved quickly because I have many customers relying on this command set extension to use my Modern DFFS solution.

Alexander

[reedpamsft]

@SPJS @juliemturner I've made a configuration change that should take effect in the next 15-30 minutes which should put you back in the state of loading "classic modern" (as Alexander puts it) when SPFX command sets are present. If you're still seeing the problem in an hour from now, please let me know.

One of us will also reach out to you later to get more details on your scenario so we can figure out why your scenarios were not working in the "new modern".

[juliemturner]

@reedpamsft - It appears to me that it's already taken affect for my dev tenant. After a few (empty cache and hard refresh) browser refreshes, in targeted release for everyone, the site collection with the list command set now is showing the lists in the old style and the command sets work whereas a site collection without any customizations has lists that show with the new list experience. Also, I created a new list in the site with the list customization and that too showed up in the older style.

[reedpamsft]

@juliemturner thanks for confirming!

[SPJS]

@reedpamsft - I can confirm that it works now - the lists in the site collection where the command set it active (installed in a site collection app catalog) shows in the "classic modern style" and the command set extension is loaded as expected.

Thanks for the quick turnaround!

Alexander

[heinrich-ulbricht]

And looking forward, SPFx will be supported in the new modern as well, right? Or is this a slow walkback on some types of customizations?

[reedpamsft]

@heinrich-ulbricht "new modern" currently supports App-level SPFX customizers, and we are working on supporting command set customizers right now (a bug in that work is what caused this recent issue).