Repository navigation
[MSFT] Rolling out support for Command Customizers in the new UI #9944
Description
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
- 💥 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
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
Activity
VesaJuvonen commentedon Sep 30, 2024
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 commentedon Oct 2, 2024
reedpamsft Vesa Juvonen (@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 commentedon Oct 2, 2024
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 commentedon Oct 2, 2024
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 commentedon Oct 2, 2024
Chris Redman (@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 commentedon Oct 2, 2024
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.listViewcontext is correctly working for lists with folders (#9908). Do you know if that's been addressed?reedpamsft commentedon Oct 2, 2024
Chris Redman (@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 commentedon Oct 2, 2024
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 commentedon Oct 3, 2024
Feets20 we have no publicly available timelines on the support of field customizers in the new UI at this point, sorry.
araLT commentedon Oct 7, 2024
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 commentedon Oct 7, 2024
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 commentedon Oct 7, 2024
Sandy Ussia (@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:
56 remaining items
joelfmrodrigues commentedon Mar 28, 2025
Natalie Ethell (@natalieethell) would you be able to confirm at this point if navigating between folders and breadcrumb nodes should trigger the listViewStateChangedEven and that it's indeed a bug? The feedback from the support team was that they would need to confirm that these user actions are expected to trigger the event since they don't seem to be documented, so just trying to get this confirmation as soon as possible in case we need to plan other mitigation actions to the issue
natalieethell commentedon Mar 28, 2025
Joel Rodrigues (@joelfmrodrigues) Yes it is indeed a bug! I'm working on a fix right now, should have it in today and rolling out to Production in the next few weeks.
joelfmrodrigues commentedon Mar 28, 2025
Natalie Ethell (@natalieethell) many thanks for the update!
joelfmrodrigues commentedon Apr 16, 2025
Natalie Ethell (@natalieethell) The fix for the event handler listViewStateChangedEvent on the new SharePoint libraries UI seems to have worked for most use cases and we can see the event being triggered when users navigate between folders and use the breadcrumb. Unfortunately, the event handler does not trigger when the user clicks on the root node of the breadcrumb, only the sub-nodes.
Our client is reaching out to premium support again to raise this via the channels available to them, but just wanted to post an update here too.
Feets20 commentedon Apr 24, 2025
Natalie Ethell (@natalieethell) reedpamsft I wanted to reach back out around some issues that were mentioned on here a little while back and see if there were any new timelines for these fixes going out?
listViewStateChangedEventnot always firing on grouped viewsIn addition to these, we're seeing some weird behavior with the expand and collapse buttons on our SharePoint lists with the new UI. Previously when we clicked these buttons it would just hide some information at the top of the list to free up some room, but now it seems to be taking us to a new URL entirely and it's an odd user experience. We spent some time trying to override this behavior using our custom SPFx but the solutions we came up with are very hacky and fragile. Has this been reported yet?
Example URL before clicking the arrow: "https://example.sharepoint.com/sites/site1/lists/testlist/summary.aspx"
Example URL after clicking the arrow: "https://example.sharepoint.com/sites/site1/lists/testlist/summary.aspx?env=WebViewList"
reedpamsft commentedon Apr 27, 2025
Feets20 thanks for the details! We've taken a few stabs at the grouped view issue, and in each case we had to walk those back because of strange side effects in certain scenarios. We have another fix that should be rolling out soon, and I'm feeling confident about it (third time's a charm?).
The behavior of the expando arrows was intentionally changed from the old experience of just hiding some chrome elements to taking users to the Lists App version of the list, which gets rid of both the top and left chrome.
We'll look into the issue with command customizers not showing up on personal views, that's either previously unreported or new...
Feets20 commentedon Jun 16, 2025
reedpamsft I appreciate the help. I wanted to follow back up and see if there are any new timelines available for a fix to the personal view issue
reedpamsft commentedon Jun 16, 2025
Feets20 thanks for the reminder. I'm seeing that you really do mean "newly created personal views". I get the repro immediately after creating a view, but when I refresh the command customizer is present. Is that what you're seeing too?
VesaJuvonen commentedon Nov 3, 2026
This issue is more than 12 months old and has not had recent activity. We are cleaning up the backlog so we can manage incoming reports more efficiently. If the issue is still relevant, please submit a new issue with updated details and current reproduction steps. We apologize for any inconvenience caused by this updated process, and thank you for being part of the SharePoint developer ecosystem.
github-actions commentedon Nov 3, 2026
Thank you for taking the time to file an issue. We periodically archive older or inactive issues as part of our issue management process, which automatically closes them once they are archived.
If you’d like to understand more about why and how we handle archived (closed) issues, please see Our approach to closed issues.
We appreciate your contribution and if this is still an active issue with the latest SPFx versions, please do resubmit the details. We needed to perform a cleanup, so that we can start with a clean table with a new process. We apologize for the inconvenience this might cause.