[MSFT] Rolling out support for Command Customizers in the new UI

[reedpamsft]

What type of issue is this?

other

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

💥 SharePoint Framework

Target SharePoint environment

SharePoint Online

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

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

Additional environment details

No response

Issue description

Hi All,

I just wanted to let you know that we are restarting the rollout of support for Command Customizers in the new Lists UI. Tenant Admins will have been notified of this through MC891238.

The behavior you can expect is that Lists in Team Sites and in the Lists App which had previously been falling back to the old UI due to the presence of Command Customizers will now start showing the New UI (with the view tabs across the top). This will rollout in a staged manner over the course of several weeks, starting with First Release/Targeted Release users, and then moving through Standard Release tenants. Please let us know if you run into issue where command customizers which were working are now no longer working, as that is the primary reason we've had to halt this rollout in the past.

We are committed to supporting the existing approved SPFX framework API's with this rollout. You may see issues where command customizers which had taken explicit or implicit dependencies on the DOM structure of the page (css classes, element heirarchy, etc.) will no longer function as expected. Please note that the DOM structure is not an API contract and is subject to change at any point (please see https://learn.microsoft.com/en-us/sharepoint/dev/spfx/enterprise-guidance for more details there).

Thanks!

Reed

[VesaJuvonen]

thx @reedpamsft on starting this thread from Microsoft side on the command support with the new lists UX.

If there are any issues you find, please do report in this issue. If you are seeing a same issue like someone else, please do +1 (👍) for the issue. We will be closely following the progress and your feedback as the feature is again rolling out worldwide.

Thank you for your input advance. Feel free to add comments and we'll guide them to the right model - create new issue if needed etc.

[Feets20]

@reedpamsft @VesaJuvonen My team has a question on this rollout, around lists with field customizers. I believe the admin center message referenced above notes that field customizers are not included in the new rollout, but can you help me understand what that means exactly?

If we have lists with both command customizers and field customizers, are we saying that these lists won't be updated at all? Or are we saying that only part of the list will be updated? We haven't been able to find clear guidance on this and we're trying to stay ahead of these updates as they'll have a material impact on our users if our tenant is updated and our code isn't ready for it.

[chrisredman01]

Similar to the question above, we have a customisation that adds a field customizer to the List after a certain action has been performed by the user.

Should we expect that the 'new' experience will apply to the List until the field customizer is added, and then it'll revert to the 'old' modern experience?

(we briefly saw this behaviour in the previous rollout, although it seemed to be cache sticky and didn't revert to the 'old' experience until a hard page refresh was performed)

[reedpamsft]

@Feets20 if there is a field customizer present on a list, the list will continue to use the old UI.

For completeness, there are 8 possible states a list can be in, and I'll present them with the expected state of the UI after this rollout is completed:

No SPFX customizers: new UI (this is also the current state of things) Application customizer only: new UI (this is also the current state of things) Command set customizer only: new UI (this is what we're working on enabling) Field customizer only: old UI Command + field: old UI Application + command: new UI Application + field: old UI Application + command + field: old UI

I hope that's clear! Let me know if you still have questions.

[reedpamsft]

@chrisredman01 that's an interesting case. Is the field customizer present on the list but hidden, or not present on the list at all, in the initial state?

From a technical perspective, if a field customizer is present on a list, it will render using the old UI. If a list goes from not having a field customizer to having a field customizer, it will go from rendering the new UI to rendering the old UI. There will be an intermediate state there where it will still load the new UI because of caching behaviors, but after a few refreshes it should settle on the old UI.

[chrisredman01]

@reedpamsft - the field doesn't exist on the List until a user does an action through the Command Customiser which calls a custom API to add the field (which is linked to a field customiser) to the list via CSOM. Sounds like it will match the behaviour we saw on the previous rollout.

Fingers crossed that the this.context.listView context is correctly working for lists with folders (#9908). Do you know if that's been addressed?

[reedpamsft]

@chrisredman01 yes, we canceled the earlier rollout in order to address that. We've confirmed with internal testing, as well as with live examples that a few helpful people were able to provide, that it's working. If you are okay providing me with your customizer to test, we can give it a try in our test environment.

[Feets20]

@Feets20 if there is a field customizer present on a list, the list will continue to use the old UI.

For completeness, there are 8 possible states a list can be in, and I'll present them with the expected state of the UI after this rollout is completed:

No SPFX customizers: new UI (this is also the current state of things) Application customizer only: new UI (this is also the current state of things) Command set customizer only: new UI (this is what we're working on enabling) Field customizer only: old UI Command + field: old UI Application + command: new UI Application + field: old UI Application + command + field: old UI

I hope that's clear! Let me know if you still have questions.

@reedpamsft I appreciate the quick reply, that makes sense. I think the only follow up question we have is if there is any plan to roll out this new UI with SPFx field customizers in the future? And if so, when that would be?

[reedpamsft]

@Feets20 we have no publicly available timelines on the support of field customizers in the new UI at this point, sorry.

[araLT]

Hi All! For now I see two issues related to SPFx extensions in new UI:

1. The default CSS styles of icons applied to SPFx list view command extensions are no more affecting on size of icons, which brings to situation when icons of size >16x16 gets outside of boundaries.

For old UI size of icons was changed to 16x16 via CSS appropriate CSS style.

The workaround for now (or later if that part is not going to be made like old UI) could be changing the specified icon size to be exactly 16x16 in extension manifest.

2. The second issue is that SPFx extensions, for which location is ClientSideExtension.ListViewCommandSet.ContextMenu is not loading at all for new UI. So, list item context menu commands added via SPFx extension are not appearing in new UI at all. I just wonder whether it is intended change (i.e. in new UI it will not be possible to add custom commands to list item context menu) or it is something that is going to be implemented yet for new UI.

[SandyLT]

@reedpamsft Is there currently any custom list scenario where the new UI will not take effect eventually? We're currently seeing some lists receiving the new UI and some not on the same sites in our Targeted Release tenant, and we can't see what the difference is, either in list creation date or configuration. Or is it just a matter of time?

[reedpamsft]

@SandyLT if you can get me a correlation ID (request ID) for a list which isn't loading the new UI, I can have a look to see why it's falling back. To get the correlation ID, you can open dev tools by pressing f12 in your browser (sometimes it will give you a prompt to double-confirm that that's what you want to do), then go to the network tab, then refresh your page. If you click the very first frame in the network trace (the aspx page hosting your list), you can look at the response headers and look for either the "Request-id" header or the "Sprequestguid" header, and then send me the value of that. Something like this:

[reedpamsft]

@araLT thanks for the feedback! Let me have a look at those and get back to you.

[jikleveland]

Are error mentioning listStartSPFxError and "Killswitches are not initialized" related to this?

Some of our users get this error both when opening libs with and without list extensions.

=>Finner ingen nettside for nettadressen https://tenant.sharepoint.com/sites/sitename sw=bypass&bypassReason =listStartSPFxError%3Berror%3DError%3A+ Killswitches+are+not + initialized. + Killswitch+requested%3A+21a3705e-d0c2-48bd-b3aa- 6e2cf41b53b3%0A++++at+e.isActivated+%28https%3A%2F%2Fres- 1.cdn.office.net%2Ffiles%2Fsp-client%2Fsp-core-library_nb- no_f9f6d863030c02b58d83.js%3A1%3A15789%29%0A++++at+D+%28https%3A%2F%2Fres -1.cdn.office.net%2Ffiles%2Fsp-client%2Fsp-application-base_nb- no_e2b94a6875ac4cfa9942.js%3A1%3A14702%29%0A++++at+new+n+%28https%3A%2F% 2Fres-1.cdn.office.net%2Ffiles%2Fsp-client%2Fsp-application-base_nb- no_e2b94a6875ac4cfa9942.js%3A1%3A25773%29%0A++++at+new+e+%28https%3A%2F% 2Fres-1.cdn.office.net%2Ffiles%2Fsp-client%2Fsp-application-base_nb- no_e2b94a6875ac4cfa9942.js%3A1%3A34527%29%0A++++at+new+t+%28https%3A%2F% 2Fres-1.cdn.office.net%2Ffiles%2Fsp-client%2Fsp-application-base_nb- no_e2b94a6875ac4cfa9942.js%3A1%3A41034%29%0A++++at+c+%28https%3A%2F%2Fres- 1.cdn.office.net%2Ffiles%2Fsp-client%2Fsp-loader-assembly_nb- no_2414a300f63e1bab4e176373c642be8a.js%3A121%3A677%29%0A++++at+https%3A%2F %2Fres-1.cdn.office.net%2Ffiles%2Fsp-client%2Fsp-loader-assembly_nb- no_2414a300f63e1bab4e176373c642be8a.js%3A

[SandyLT]

@SandyLT if you can get me a correlation ID (request ID) for a list which isn't loading the new UI, I can have a look to see why it's falling back. To get the correlation ID, you can open dev tools by pressing f12 in your browser (sometimes it will give you a prompt to double-confirm that that's what you want to do), then go to the network tab, then refresh your page. If you click the very first frame in the network trace (the aspx page hosting your list), you can look at the response headers and look for either the "Request-id" header or the "Sprequestguid" header, and then send me the value of that. Something like this:

@reedpamsft Here is the Request-id of one of my lists that has not received the new UI, when others in the same site have: ecd158a1-b0f8-a000-088f-6863c8a0b1b2. This list was created a few years ago, as was another list that does have the new UI: 28d458a1-104f-a000-25b0-97cb3046ebe5. Our custom command bar extensions are working on both lists, even without disabling Offline Availability. As far as I can see, both lists include the same column types, and have the same settings. This tenant is in targeted release. Thanks for any feedback you can provide. We're also seeing what appears to be inconsistency as to when the new UI prevents the command bar extensions from appearing and when it doesn't. For example in the 28d45 list I mentioned above, the new UI is not preventing the extensions from being displayed, but in another targeted release tenant (and for many of our customers), I needed to disable Offline Availability to display the extensions. Both tenants I've mentioned were created in 2016, in case that helps to know.

[SandyLT]

@SandyLT if you can get me a correlation ID (request ID) for a list which isn't loading the new UI, I can have a look to see why it's falling back. To get the correlation ID, you can open dev tools by pressing f12 in your browser (sometimes it will give you a prompt to double-confirm that that's what you want to do), then go to the network tab, then refresh your page. If you click the very first frame in the network trace (the aspx page hosting your list), you can look at the response headers and look for either the "Request-id" header or the "Sprequestguid" header, and then send me the value of that. Something like this:

@reedpamsft Here is the Request-id of one of my lists that has not received the new UI, when others in the same site have: ecd158a1-b0f8-a000-088f-6863c8a0b1b2. This list was created a few years ago, as was another list that does have the new UI: 28d458a1-104f-a000-25b0-97cb3046ebe5. Our custom command bar extensions are working on both lists, even without disabling Offline Availability. As far as I can see, both lists include the same column types, and have the same settings. This tenant is in targeted release. Thanks for any feedback you can provide. We're also seeing what appears to be inconsistency as to when the new UI prevents the command bar extensions from appearing and when it doesn't. For example in the 28d45 list I mentioned above, the new UI is not preventing the extensions from being displayed, but in another targeted release tenant (and for many of our customers), I needed to disable Offline Availability to display the extensions. Both tenants I've mentioned were created in 2016, in case that helps to know.

[reedpamsft]

@SandyLT that first list has Field customizers present, which are not currently supported by the new UI, so it's expected that they fallback.

Regarding the second question, there is a known issue with Sync not serving command customizers, in both the old and new UI's. They're working on it, but in the meantime you can turn off sync for a list to see the customizers.

[Ryan-Shrestha]

@Feets20 if there is a field customizer present on a list, the list will continue to use the old UI.

For completeness, there are 8 possible states a list can be in, and I'll present them with the expected state of the UI after this rollout is completed:

No SPFX customizers: new UI (this is also the current state of things) Application customizer only: new UI (this is also the current state of things) Command set customizer only: new UI (this is what we're working on enabling) Field customizer only: old UI Command + field: old UI Application + command: new UI Application + field: old UI Application + command + field: old UI

I hope that's clear! Let me know if you still have questions.

Is there a way to revert back to the Old UI so the field customizer works

[reedpamsft]

@Ryan-Shrestha if you have a field customizer, you should currently and will continue to see the old UI, yes.

[Feets20]

@reedpamsft My team is working through some command set customizer updates and we noticed some issues, specifically with grouped views, when leveraging this.context.listView.selectedRows. More specifically, we've added an event handler to this.context.listView.listViewStateChangedEvent so that we can hide / display certain buttons in the command set customizer depending on what is selected, and selecting list items in the grouped view intermittently does / does not trigger this event handler. This issue isn't something that we're running into on the non-grouped views.

I wanted to see if this was a known issue? Or if there is something different that we should be doing on our end to handle grouped views better?

For context, we had a separate support ticket opened with Microsoft and we were able to get some of our developers' local development M365 tenants updated with the SPFx-supported List UI update, to assist us in prepping for the larger rollout to our business tenant.

[reedpamsft]

@Feets20 thanks for the info! SPJS has also reported an issue with this.context.listView.selectedRows, so we'll look into this as well.

[Feets20]

@Feets20 thanks for the info! SPJS has also reported an issue with this.context.listView.selectedRows, so we'll look into this as well.

@reedpamsft Thank you for all of your help. For our understanding, what was the issue raised up by SPJS?

[reedpamsft]

@Feets20 this is what I'm referring to: https://github.com/SharePoint/sp-dev-docs/issues/9978

[Feets20]

@reedpamsft Today in our business tenant we're seeing some intermittent cases where this new List UI is applying to lists which have field customizers, then after a few refreshes it goes back to the normal UI. I wanted to reach out here to see what the experience will be when this hits our tenant? The intermittent back and forth will be disruptive to our business and I would like to understand that experience a bit more.

Does having a list item on the list impact whether or not the new UI displays, regardless of whether a column on the list is associated with a field customizer or not? More specifically, will the new list UI display on an empty list, and then once I add an item the old UI will go back?

Thanks again for your help

[reedpamsft]

@Feets20 when the feature rolls out, the experience should be that you'll always get the new experience with no flipping back and forth.

If you are able to, a correlation ID (or even better: network trace) of a time when the old experience loads vs. a time when the new experience loads would be helpful; I can use those to find out why you're loading one or the other based on the server logs. The correlation id is the "spreqestguid" or "request-id" header returned by the server for a page load. If you want to share the network traces, you can replace the "msft" in my github user name with "[at]microsoft.com" to email them directly to me if you don't want to share them here.

[reedpamsft]

Sorry, I should mention that the experience now should be that you should get the old experience without flipping back and forth (as long as a command customizer is present).

If you add a command customizer to a list, there might be a brief period of a few page loads where you'll flip back and forth as the various caches work themselves out.

[Feets20]

@reedpamsft When you say command customizer, you mean field customizer, right? Our situation is that we have command and field customizers on all of our lists, but we still briefly saw the new UI on some of those lists for some reason.

My specific question is if it matters whether or not a list item exists in the list, for the field customizer to still trigger the old UI. For additional context, we definitely want the old UI to be applying on our lists right now as our SPFx won't work right with the new UI

[reedpamsft]

@Feets20 sorry. If you have both command and field, then it should always load the old UI. If you can get me a correlation ID or network trace for a case where it's loading the new UI, I can try to troubleshoot. It should be loading the old UI.

[Feets20]

@reedpamsft Thanks for the quick information. I think my last question around this, for our understanding, is how the SP code determines whether a field customizer is involved. At a low level, is this determined at the field or list definition level?

For example, if I had List A on my site, which had Field 1 on it, which was associated to a field customizer, does that mean that List A would always show the old UI, even if there were list views that didn't have Field 1 on them?

Sorry for all of the questions, but this information will drive some of our prioritization discussions with our stakeholders. Thanks again

[Feets20]

@reedpamsft We're also seeing some slowness with our lists loading now, starting today. We're seeing an average of ~15 seconds for our SharePoint lists to load any work items

[reedpamsft]

@reedpamsft Thanks for the quick information. I think my last question around this, for our understanding, is how the SP code determines whether a field customizer is involved. At a low level, is this determined at the field or list definition level?

For example, if I had List A on my site, which had Field 1 on it, which was associated to a field customizer, does that mean that List A would always show the old UI, even if there were list views that didn't have Field 1 on them?

Sorry for all of the questions, but this information will drive some of our prioritization discussions with our stakeholders. Thanks again

To the best of my knowledge, if there's a field customizer associated with the list, it will load the old UI, but if you see something different please let me know.

[reedpamsft]

@reedpamsft We're also seeing some slowness with our lists loading now, starting today. We're seeing an average of ~15 seconds for our SharePoint lists to load any work items

@Feets20 can you share a correlation ID? Let me know if you're not sure how to see the network headers and I can give a little walkthrough.

[Feets20]

@reedpamsft Here are some sprequestguid's from various list loading scenarios where it took a while to load, for one of our test sites on our business tenant

9d145fa1-e005-6000-cd34-23f0eff68ee1 af145fa1-408e-6000-c5da-da5ac74a39be bb145fa1-7048-6000-cd34-2e67922124f7 ca145fa1-3027-6000-e02c-45c16936f1a2

[reedpamsft]

@Feets20 thanks! I'll have a look.

[reedpamsft]

@Feets20 were these all on the same computer, or different machines? In that first one I'm seeing that Index DB accesses are taking an excessive amount of time, which can suggest either resource contention (mining crypto? ;) ) or the hard drive is dying. In both the first and second, I'm also seeing that the list sync engine is taking a very long time, so it might be helpful to terminate the "microsoft.sharepoint" process in task manager and see if that fixes things. So, my main suggestions would be to try a different computer, and if that's not possible then try restarting. If that doesn't help, try ending the microsoft.sharepoint process, and if that doesn't help them let me know and I'll look deeper.

[estruyf]

@reedpamsft With the new list experience, we are experiencing some issues where the command(s) do not show up on newly created items. Only when the page is refreshed do the commands become available.

Here you can see the behavior:

https://github.com/user-attachments/assets/24e203e8-f6d5-4df8-8181-4f2219e2b059

When you select an existing item in the list, the context.listView.listViewStateChangedEvent event of the command customizer gets triggered, but this doesn't happen for the new items.

The same happens for the this.context.listView.selectedRowsChangedEvent event.

https://github.com/user-attachments/assets/9fb05793-eab9-49d6-b88a-7e2f4c3e9507

[reedpamsft]

Thanks for reporting @estruyf , we're looking into it.

[Feets20]

@reedpamsft With the new UI experience, we're running into some issues when editing in grid view mode and trying to update taxonomy fields. Clicking on the fields once or twice results in the cell going blank and not being able to select a new term for that field

[reedpamsft]

@Feets20 thanks for reporting! I'll see if I can reproduce and maybe ask for a few more details if I can't...

[reedpamsft]

@Feets20 unfortunately, they appear to be working okay to me. Can you share a little video/gif?

[Mcmo7]

Unsure if this is linked to this rollout:

https://github.com/SharePoint/sp-dev-docs/issues/10010

[reedpamsft]

@Mcmo7 no, form customizers are not related to this. They were already incorporated in the original rollout from MC709979 (completed in May).

[Feets20]

@reedpamsft Our business tenant got updated today with the new List UI. Something that we're seeing which is problematic for us is if you create a list view and don't select the field(s) which have field customizers on them for that particular view, the new UI is applied when that view is selected. Is this intentional? I was under the impression that this was determined at a list level and not at a view level.

[reedpamsft]

@Feets20 thanks for letting me know. That does sound like a bug, although probably one that has been around for a while since we haven't touched the field customizer logic since Feb.

[smukked]

CustomAction RegistrationId not working with new UI. ListView Commands with RegistrationId="101" should only be loaded on document libraries, but they are added to lists and document libraries.

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
    <CustomAction
        Title="SPFxListViewCommandSet"
        RegistrationId="100"
        RegistrationType="List"
        Location="ClientSideExtension.ListViewCommandSet.CommandBar"
        ClientSideComponentId="5fc73e12-8085-4a4b-8743-f6d02ffe1240"
        ClientSideComponentProperties="{&quot;sampleTextOne&quot;:&quot;One item is selected in the list.&quot;, &quot;sampleTextTwo&quot;:&quot;This command is always visible.&quot;}">
    </CustomAction>
    <CustomAction
        Title="SPFxListViewCommandSet"
        RegistrationId="101"
        RegistrationType="List"
        Location="ClientSideExtension.ListViewCommandSet.CommandBar"
        ClientSideComponentId="5fc73e12-8085-4a4b-8743-f6d02ffe1240"
        ClientSideComponentProperties="{&quot;sampleTextOne&quot;:&quot;One item is selected in the list.&quot;, &quot;sampleTextTwo&quot;:&quot;This command is always visible.&quot;}">
    </CustomAction>
</Elements>

Source: Add a ListView Command Set to a solution package for deployment