-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[MSFT] Rolling out support for Command Customizers in the new UI #9944
Comments
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. |
@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. |
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) |
@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) I hope that's clear! Let me know if you still have questions. |
@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. |
@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 |
@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. |
@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? |
@Feets20 we have no publicly available timelines on the support of field customizers in the new UI at this point, sorry. |
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. |
@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? |
@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: |
@araLT thanks for the feedback! Let me have a look at those and get back to you. |
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 |
@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. |
1 similar comment
@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. |
@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. |
Is there a way to revert back to the Old UI so the field customizer works |
@Ryan-Shrestha if you have a field customizer, you should currently and will continue to see the old UI, yes. |
@reedpamsft My team is working through some command set customizer updates and we noticed some issues, specifically with grouped views, when leveraging 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. |
@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 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 |
@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. |
@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. |
@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: Screen.Recording.2024-10-31.at.10.29.19.movWhen you select an existing item in the list, the The same happens for the Screen.Recording.2024-10-31.at.10.43.27.mov |
Thanks for reporting @estruyf , we're looking into it. |
@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 |
@Feets20 thanks for reporting! I'll see if I can reproduce and maybe ask for a few more details if I can't... |
@Feets20 unfortunately, they appear to be working okay to me. Can you share a little video/gif? |
Unsure if this is linked to this rollout: |
@Mcmo7 no, form customizers are not related to this. They were already incorporated in the original rollout from MC709979 (completed in May). |
@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. |
@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. |
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="{"sampleTextOne":"One item is selected in the list.", "sampleTextTwo":"This command is always visible."}">
</CustomAction>
<CustomAction
Title="SPFxListViewCommandSet"
RegistrationId="101"
RegistrationType="List"
Location="ClientSideExtension.ListViewCommandSet.CommandBar"
ClientSideComponentId="5fc73e12-8085-4a4b-8743-f6d02ffe1240"
ClientSideComponentProperties="{"sampleTextOne":"One item is selected in the list.", "sampleTextTwo":"This command is always visible."}">
</CustomAction>
</Elements> Source: Add a ListView Command Set to a solution package for deployment |
@reedpamsft There's an issue that we've uncovered with the new UI, I'm not sure if it's reproducible on your end or not. We're finding that our custom command customizer buttons aren't showing on newly created personal views. We're finding that the buttons start to "register", or show correctly once we've made that a public view |
@Feets20 thanks for the report! We'll look into it. |
@reedpamsft In the new UI it seems like the context is not updating changes in the items when using the grid view. |
@reedpamsft I appreciate all of your help hearing us out on the issues that have been raised up in this thread. I did want to follow up this morning on this issue that was brought up a couple of weeks ago. In general with these issues and their resolutions, is there going to be a need for us to upgrade our SPFx version that we're using to see some of these fixes in the future? |
@Feets20 sorry for lack of updates; the fix for the issue you mentioned is being worked on. In general, we've been pursuing bug fixes to the core product, which shouldn't require any work from you to pick up. |
Mentioned 2 issues does not exists anymore, however we noticed new issue when using SPFx extension, for which location is ClientSideExtension.ListViewCommandSet.ContextMenu. Without extension, item context menu contains commands Details and More in the bottom (shown in the following screenshot): However when there is extension with location ClientSideExtension.ListViewCommandSet.ContextMenu, which adds some commands in item context menu, then mentioned built-in commands (Details and More) disappear: |
@reedpamsft Hi! Would you please be able to take a look at the above post from @araLT and advise whether we can expect an update from Microsoft on this? Or let us know if it should be raised elsewhere? It seems that in fixing the issue raised in the October 7 post above in order to display custom extensions, the built-in Details and More commands have been removed or replaced. Those commands had previously appeared beneath the custom commands. This issue has been raised with us by a very large client organization whose users require the Details option in order to view an item's properties, since that's no longer available in the upper right area of the new list UI. For now, the workaround for this client is for them to disable our context extension in the TenantWideExtensions list, but that's not a long-term solution. Thank you in advance for looking into this 😊 |
@reedpamsft Unfortunately we're still experiencing these problems and it's impactful to our users. Will there be communication on any timeline for remediation of these problems? |
@Feets20 sorry, we are working on it. It's a complicated one. |
Great, thanks, @reedpamsft !! |
@reedpamsft I'm not sure if this has been raised up elsewhere, but we're having trouble editing items in grid view. Nothing seems to be updated / happening when we do this in the new List UI |
@Feets20 no, that's new. Can you try to grab a video? |
@reedpamsft Please see the attached video for reference. I was able to get 1 out of the 2 fields to update in the recording, and you'll see me refresh the screen a couple of times. The test site I'm using in the video has a custom content type, but other than that it's just a vanilla list without any SPFx running on it. Please let me know if I can provide any additional info. EditInGridViewDemo.mp4 |
Note that the Grouped View issue has been fixed and will roll out with new client builds in January (build rollout is paused for the next two weeks per msft policy). |
@Feets20 thanks! That's a complicated one, unfortunately. Clicking directly from a cell that's being edited onto the "exit grid view" button will lose your changes. One of the folks who reports to me is working on it, and I'm hopeful it will get fixed soon... anyway, the workaround is what you demonstrated in the repro, which is to click off of the cell to anywhere other than "exit grid view" before clicking "exit grid view". |
@reedpamsft Thanks for the info and the quick responses, I appreciate it |
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
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
The text was updated successfully, but these errors were encountered: