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
• 💥 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).

[florianwachter]

Is there an update on the issue? Recently some of our customers reported this issue in personal views. Command sets and field customizers are suddenlty gone.

[s-KaiNet]

We have the same problem related to this issue.
We have a command set for document libraries. If we use document library web part, it uses "New Modern UI", and the command set isn't loaded at all. We've tried disabling "Offline Client Availability", but seems it doesn't work for document libraries. Currently, the problem hit one customer, but looks like it will grow.

Are there any additional info about this problem? I'ts the end of August and seems people struggle with it for a few months already.

EDIT: the issue happening with document library web part.

[MortenGuldbaek]

We are experiencing the exact same as @s-KaiNet currently and also hoping for some good news as consistent Command Sets are vital for our business.

[natalieethell]

@yur-st @s-KaiNet @MortenGuldbaek Thanks for reporting. We've identified the issue specific to the document libraries webpart and have reverted to the "old" UI. You should be seeing your SPFx command customizers in your document libraries webparts again in the "old" UI.

We are ensuring that the SPFx command customizers issue in the webpart is fixed before we push the "modern" UI again.

[AJIXuMuK]

Hey folks - this thread is getting too long and reference a few different issues, although all of them are related to new UI for lists and document libraries.

To summarize, there is still an issue with offline mode for the lists.
And here is the workaround for it: #9514 (comment)

For web part you should see "old" UI being enabled.

The team is ensuring that the new UI will not break SPFx extensions when enabled.

I will close this one as it's getting hard to track.
Please, create new issues and reference this one if needed.
Also, provide information like:

• type of extension
• document library or list
• full page or web part

I would also encourage you to name the issue with SPFx in lists (same as label for this issue) to be able to triage it faster
The team will be monitoring new items in the repo while rolling out the new experience.

Thanks!

[s-KaiNet]

Thanks @natalieethell for the fast response and the fix. I can confirm, that on two of our tenants, where we previously observed the issue, now document library web parts use "old UI" and all command sets work as expected.

[smolattack]

The team will be monitoring new items in the repo while rolling out the new experience.

Why weren't you doing that to begin with?

[silentmark]

Why is this issue closed?

[juliemturner]

@silentmark -- please read the comment above #9514 (comment)

[smolattack]

Why is this issue closed?

Because it is getting "hard to track" the mess they made.

[BlazeOfFeathers]

I just discovered that command sets are still functional in the new UI! The only thing that has changed is the handling of event.selectedRows. To make your code work again, simply replace it with this.context.listView.selectedRows.

[JurajSlavik]

@BlazeOfFeathers : Thank you very much, confirming it`s working. Solving the issue reported here: #9898 (comment)

In case you do not want to change all occurences to this.context.listView.selectedRows, you can make it in the beginning of the onExecute, similarly to this:

[wuxiaojun514]

@BlazeOfFeathers Thanks very much! This solution is working for me!

[PKOITC]

I just discovered that command sets are still functional in the new UI! The only thing that has changed is the handling of event.selectedRows. To make your code work again, simply replace it with this.context.listView.selectedRows.

What version of SPFx do I need to use for that workaround ? Version 1.12.1 gives me "Property 'selectedRows' does not exist on type 'ListViewAccessor'" error.

[buettiB]

@BlazeOfFeathers: That helped us as well. Thanks!
BTW: Yesterday our button did not show up in most Tenants and Lists. This morning the button was there, but without functionality. The workaround above made it work for us again.

[shaipetel]

I'm also surprised and confused, why close this issue if the fix for the original issue is still not resolved... It is even harder to track if you close this one and asking people to report the same issue in duplicates, so I'm not sure what's the point?

[adriangoszczynski]

As of this morning, we have reverted to the previous UI in our tenant, without any info from MS.

[henningeiben]

does anyone know (@BlazeOfFeathers) if this.context.listView.selectedRows is just a workaround or is this the expected way to access this information in the future? Is there any official notice on this "change"?

[juliemturner]

@henningeiben - no official statement has been made about that change, until it is I would consider it a hack to get things working and would either wait or inform my clients that making that change could break at any time. That said, per @adriangoszczynski comment I would suggest that the amount of noise that is being made is helping raise visibility and they have decided to revert changes so that things can be better handled. At least I hope that will be the case. Again, sadly, nothing official.

[henningeiben]

@juliemturner: in the meantime I addressed this also in issue #9896 - maybe this helps as well

[andrewconnell]

+1000 to what @juliemturner said... the way Microsoft is handling this issue leaves A LOT TO BE DESIRED.

If you encounter this issue, there's no one place that says what the issue is or what the resolution or current status is... I mean I guess that's this issue, but you have to read the play by play to figure out what's going on. The fact it was closed & marked as completed by @AJIXuMuK makes it seem like the issue has been resolved when it clearly hasn't.

As @shaipetel said in his comment, the approach of creating fragmenting this to multiple issues is making it even harder to follow.

Sure seems to me the new List UX wasn't ready to ship because it didn't account for SPFx customizations, breaking established practices. Regardless if it's one issue or 50 issues, it's one feature that's getting reverted & seems like one issue should be used to track it.

Hoping Microsoft makes an official statement either here in the issue list, or in the docs... but it's something we can point customers to, because it sure isn't being well received by customers.

Dear @VesaJuvonen ... #help

[reedpamsft]

@andrewconnell the other thread was closed because the specific bugs it was discussing had been fixed and confirmed as fixed by the folks who reported the issue.

[juliemturner]

@reedpamsft is there a place you would like us to submit bugs with the new lists experience that aren't related to SharePoint Framework?

[andrewconnell]

@reedpamsft said:

@andrewconnell the other thread was closed because the specific bugs it was discussing had been fixed and confirmed as fixed by the folks who reported the issue.

Which "other thread" are you referring to? The issues linked in this one are all open... sorry, just asking for a single link we can share with customers who are still confused who want to hear it from Microsoft.

[reedpamsft]

@juliemturner maybe create a new thread and at-mention me? Github seems to have removed the ability to send private messages.

[reedpamsft]

@andrewconnell I'm referring to the thread that Florian had created and which was marked as closed. I understand that having multiple threads can be confusing in some ways, but having a single thread where different issues are piled on makes it difficult to differentiate which are still active and which are resolved.

[shaipetel]

@reedpamsft seems like MSFT are now dropping updates directly to production, targeted release no longer getting a heads up with the new new new list experience...

I just reported an issue that started happening last Friday and tagged you, and this release also broke many of our forms based solutions due to now opening forms in a dialog.

Is MSFT not following the targeted release anymore? is there another way for us to be able to taste/test the drops before they hit production?