SPFx ListViewCommandSet Extensions are no longer being loaded when switching list context in side navigation!

[frevds]

Category

• [x] Bug

Describe the bug

Okay, let't try that again in the right section.

I registered a ListViewCommandSet Extension for a list. But the extension is not being loaded, if I don't directly navigate to that list:

If I open the list page for a list for which the extension is activated, the extension gets loaded (constructor called, onInit called).

If I open the list page for another list for which the extension is not activated and then navigate to the list for which it is activated, using the navigation tree, the extension does NOT get loaded.

Also, if the extension was loaded for a list and the user switches to another list using the navigation, any extension activated for that list does not get initialized (constructor or onInit is not being called again).

Finally, the onListViewUpdated-Event never worked.

This issue makes list view command set extensions quite useless and breaks our product. Is there any fix coming for this or should we move on to generic extensions loaded for every page?

Steps to reproduce

Use the yo generator to create a new ListViewCommandSet and try on your own to get it loaded for a list if you don't directly navigate to it (in SharePoint Online), see details above.

Second problem: the onListViewUpdated-Event never fires, no matter what you do in the ListView (provided the extension was loaded at all).

Expected behavior

Extensions should be loaded for lists on which they are registered, when you navigate to the list (using the navigation). Currently they are only loaded if you directly enter the correct list when opening the browser page, not when navigating in the tree (where the page does not reload but merely React controls get rerendered). This behaviour did work before, but is now broken.

Second problem: Changes in the selection of the list view should fire the event. Maybe even changes to the list context (navigating).

Environment details (development & target environment)

• OS: Windows 10
• Target Environment: SharePoint Online
• Framework: Node.js v10
• Browser(s): Chromium Edge latest
• Tooling: SPFx v1.10.0
• Additional details: Suspecting latest changes in SPO, client and solution did not change

Additional context

[msft-github-bot]

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

[chr-sad]

Can confirm the problem in our SPFx v1.10.0 CommandSet Extension as well. The CommandSet is only loaded correctly if directly accessed. If we use left navigation, the extension is not initialized an onListViewUpdated is never fired. If we reload the page with F5 or STRG+F5 the extension on the same list is loaded and works till we navigate to another list in the left navigation.

[RowanAdvisors]

I would also like to point out that we are experiencing the exact same issue, but filtering the view even when navigating directly to the list/library causes the command set extension to bug out and stop working.

[chr-sad]

@RowanAdvisors I just tried to reproduce the filtering issue but I can not confirm a problem here. At least in our solution on our tenant even when filtering is active, the CommandSet Extension works correctly for our use case.

[frevds]

Yes same for me, filtering does not do anything bad to our extension, but then our extension does not add any toolbar buttons. What does "bug out and stop working" mean in your case @RowanAdvisors?

[Debopoma-netwoven]

I am facing the same issue:When the document library is opened for the first time from quick launch menu(left navigation menu) it loads the Command bar spfx extensions But when we switch to another library from quick launch it does not refresh the whole page and as a result
this time the command bar spfx extension does not load.It only loads after we refresh the entire page/press F5

[barisbikmaz]

Same here. Command only appears on the first list. When navigating to another list over the left navigation the command bar is not shown anymore.

[69mustang302]

I just upgraded to SPFx v1.10.0 and can confirm this behaviour. When navigating to another list using the quick launh, the commandbar does not refresh nor is there any hit on onInit of the BaseListViewCommandSet. Currently this is blocking our corporate deployment.

[frevds]

@69mustang302 Are you implying that this is not a SharePoint issue but a SPFx framework issue, i.e. does this all still work with SPFX < 1.10?

[69mustang302]

@frevds Just checked on another tenant that still has the 1.9.1 version running of my solution, and no, it's a SharePoint issue, same behaviour there! And another non-related issue : https://github.com/SharePoint/sp-dev-docs/issues/5681 But also caused by changes on SharePoint.

[frevds]

@69mustang302 Yes, that's how it should be. So far so good. It seems when they changed their React app recently, they "forgot" about the extensions. It should be a simple matter, but of course will take forever before we see any new release. But I expect this issue will get solved eventually, since extensibility of SharePoint using SPFx is kind of important enough. And if not, well, then I guess we'll have to switch to ApplicationCustomizers being loaded on every modern page.

[69mustang302]

Let's hope for a quickupdate, and well, i guess you could (ab)use ApplicationCustomizers in that way ;) Lets keep an eye out for the version update of spo, you can find your version here:

[frevds]

If I'm not mistaken I think the extensions do load again after navigating in the tree. Can somebody confirm that? Seeing odsp-next-prod-webpack_2020-06-05-sts_20200611.001 here.

[69mustang302]

On my tenant I have the same version update to 2020-06-05. Something has changed, however the onInit() now only excecutes twice The scenario is as follows:

1. I open the list targettted by the extension by browsing to the url (refresh) : onInit() executes.
2. I navigate using the quick launch to a list that is not targetted by the extension: onInit() excecutes - that's what we want!
3. I navigate to the targetted list using the quick launch : onInit() does NOT excecute.
4. Repeated navigations, changing lists does not trigger onInit()

Only refreshing the page with [F5] allows you to repeat the above scenario. So unfortunately, it is not yet the fix we hoped for...

I want to point out that also this (related) issue is still not solved with this version : this.context.listView.columns is an empty array #5681

[frevds]

@69mustang302 I can confirm that onInit is only called ONCE per targeted list, but i can NOT confirm that onInit is called for non-targeted lists. So if I navigate to a list that is targeted, the extension gets initialized, when I navigate to another targeted list, the extension gets initialized (now with the latest update; this was the original issue). When I then navigate back (using the left-side tree or the browser Back button) to the earlier targeted list, the onInit is not called again (I don't do integrations such as buttons, only page context manipulations, so this is fine for me, but I don't know whether regular interactions with the list view require repeated onInit calls). And if I navigate to any non-targeted list, nothing happens (which is how it should be).

[69mustang302]

@frevds A ListView CommandSet should fire on every list visit. In a listview commandset extension, in onInit() you can then decide to show or hide buttons in the commandbar depending on the context of the list provided through this.context . What I call a " targetted" list is a list which meets my functional requirements and should show my custom buttons and react to item selection depending on your functional requirement. In this video i demonstrate the effect: ListViewCommandSetDemoVideo. As you can see, the custom buttons appear when visiting the list, however after navigating slolely using the quick launch. The custom buttons do no get rendered again. So imho it's not fixed....

[frevds]

@69mustang302 Ah yes, indeed, that's not solved then, if the UI extensions cannot be reestablished. Good that we clarified the term "targeted". I refered to lists for which the SharePoint-Custom-Action was deployed (I do this via list.UserCustomActions.Add). Well, I reckon, since there was no response here yet from people involved, that they're still in the middle of it. But good to see some progress. It does suffice for me (as I'm merely using onInit to hack into the ActionMap, which needs to be done only once), but I'll leave the ticket open until this is working completely.

[frevds]

PS: @69mustang302 The other ticket about this mentions some workaround (where you can force a reload of the whole page when navigating): https://github.com/SharePoint/sp-dev-docs/issues/5776#issuecomment-640717900

[69mustang302]

@frevds Thanks for leaving this open, and yes, clarity is key ;) In my scenario, the extension is bound to multiple lists, and is activated depending on the list’s properties, rather than being bound to one list. So we’ll keep monitoring this issue. Thanks for the link to the possible workaround, however we have deployed some 2000+ site collections, hence it is not feasible to instruct users to update their quicklaunch without being buried in support cases...

[frevds]

@69mustang302 Another possible workaround in your case: Since the page URL (location.href) changes during navigation in the tree, you could have a background task (Javascript's setInterval) running to check every 200msec whether the URL is still the same (or similar mechanism to detect changes). If it did change, do a location.reload() to reload the whole page and have your extension activate again. Not pretty but should patch the issue until the time comes when SharePoint fixes it (for a graceful transition store the expected URL in a global variable so all instances of your extension access the same URL (and the URL should only be the location.pathname), then when they fix it, your new extension will set this variable when being activated before the old extension's timer recognizes a change). The timer itself should also be singleton, i.e. stored in a global varialbe and only started if not yet running.

[waaromikniet]

I'm still facing the same issue. The problem in my case is that the oninit() for my command set is only executing once. I use the oninit() to enable or disable the command on specific lists. When navigating my lists using the quick launch the oninit() is not fired when opening a list I already opened before.

6116

I am on this version

[ltdu]

We have the same problem. Very simple command bar extension is loaded correctly only if view page is opened directly. It is NOT loaded if we navigate to view from another site page "in-page" (without full page reload).

[dixonte]

I might be having the same issue. However for some reason the issue is only occurring with one of my ListViewCommandSet solutions, and not the other. It seems the main difference is that the one that stops working is deployed without a List Template being set.

[S-e-b-i]

Hello, any news on that (from the SharePoint/SPFx-Team)?

We're facing the same or a similar issue: coming from a SitePage (e.g. Home.aspx) and clicking on a top-navigation-node which (indirectly, see below) targets another SitePage (e.g. SubWeb/SitesPages/MyPage.aspx?WithUrlParameters) the MyPage.aspx will be loaded, BUT all additional (and in our case important) URL-parameters get removed!?!^ :-(

This SitePage-URL was set as [SubWeb].RootFolder.WelcomePage-property so that surfing to /SubWeb automatically opens the desired page (with parameters). Doing that manually - or coming from a page not hosted in SitesPages - works fine! Only when clicking on the navigation-node the parameters get lost. :(

Any idea how to fix this (on our side)?

Thanx in advance and nice regards, Sebastian

[trillian74]

Hi guys. Just wanted to also add that i am experiencing the same as described in this thread. A customer of mine is not very happy:/ even though i cannot do anything about it. scenario is

It works when i enter the library from any other place than the Home link in QL, when i enter the library from Home QL link i need to do a refresh to get it working....

It has so for a while. I luckily stumbled onto this thread to see that i'm not alone. It doesn't help, but maybe it'll get sorted...

I have upgraded the command set to 1.11 and the prodpack says files/odsp-next-prod-webpack_2020-08-21-sts_20200909.001

Would be great to get this sorted (or if someone has a good WO)

thanx in advance and best regards Ole

[trillian74]

This is still a problem for my command set. When i access the list when on "Home" via Quick Launch then i must do a refresh to get the command set button to react.

if i just copy the library link into a browser then it works. If i access the library from any other place than Home it works. Must be a bug. @frevds @andrewconnell

current webpack: odsp-next-prod-webpack_2020-09-11-sts_20200925.002

[tarjeieo]

Seeing this exact issue in some customer tenants with spfx 1.9.1

[ssandu]

Some issue here with 2 customers. It's happening only on new site collections (created in the last month). Old site collections don't have this issue.

[vlad-nvs]

Can confirm that this issue still could be reproduced. If navigate to list/library from Client-Side page OnInit fires only after ~1-2 min and Search placed in wrong place.

Any news about this issue?

[ssandu]

Seems to be resolved now

[waaromikniet]

Seems to be resolved now

I still have the issue on old and new sites

[trillian74]

@ssandu I did a small check on one tenant of mine where i've experienced this and it seemed to work properly now. Will monitor it for a little while before i conclude. I've also informed the users that the bug should be gone and that they should inform if it happens again... fingerscrossed

[waaromikniet]

I did a test on multiple tenants. It doesn't work on any my tenants. Problem is oninit() is only executed once. Like my helloworld example mentioned here #6116 @trillian74 and @ssandu can you confirm that your oninit() is executed everytime you click on the link in the left nav

[frevds]

Same here, onInit is still called only once per extended List (but at least that works now).

[probably-a-toaster]

One of my customers is having this exact issue using the ListViewCommandSet extension. It has the same behaviour as the example mentioned in #6116. Hopefully there'll be a fix coming soon because this is a really annoying bug.

[tripleseven73]

Found my way to this posting after running in to the same problem as described. The issue seems to be related to the partial page rendering which SharePoint performs when navigating using side navigation. I suspect that beause of this partial page rendering certain (SPfx related) information is not being property (re)initialized causing the command set to break down at a certain point. I also noticed this failure to (re)initialize when reading context.pageContext.list.title which often returns the title of the list I previously visited instead of the one that is currently being displayed.

Hitting CTRL + F5 resolves the issue momentarily; deleting and recreating the menu items without .aspx also seems to work (seems to disable partial page rendering) but this is not a workable solution considering the number of (sub)sites already in operation.

[westleyMS]

OnInit is only called if the navigation is not performing partial page rendering, the first time you go to the list. after that, the command set stays loaded and only calls onListViewUpdated() on the first load and anytime you change the list selection. This is all by design, but it does leave some holes when using multiple command sets when you want to hide and show items. This is especially true when you want to have the command set only show on certain lists, as it leaves you w/o a way to trigger the hiding of the command. Page navigation event is not available on the context object for command sets. @patmill is there any guidance you can provide on how we can accomplish this? Is there a way to get the page nav event to trigger the show/hide code based on list names or urls?

[patmill]

Can you give an example on how the onListViewUpdated is insufficient? My understanding is that the Updated method should be called when you switch between lists, as well as when a single list is updated. If that isn't firing, then that sounds like a bug.

[waaromikniet]

Check my example in #6116 We expect the oninit to fire every navigation change.

[patmill]

No, onInit won't fire on every navigation change. Like I said though, how is onListViewUpdated insufficient to meet requirements? Is it not firing when navigating from list to list? Is the context not updated to know if you should show information?

[waaromikniet]

I have to test with that event. I was expecting, when you navigate to a new item in quick navigation, a new request is made and the oninit() would fire. Even when you already visited that item.

[patmill]

Understandable, but no. Running through the entire page render lifecycle has a big hit on page speed, so wherever possible we keep everything running and update the frame / fire events / etc. The same applies to app customizers. If we need to hook up the navigation event we could, but if the onListViewUpdated fires, then it would make life simpler for the developer (only one event to deal with) Please post back if it works / doesn't work / questions.

[frevds]

@patmill The onListViewUpdated event does not fire at all and never has, at least in my commandset extension. Maybe I'm doing something wrong.

[westleyMS]

@patmill I just tested with 2 list command sets, and when I do a partial page nav to the list, they don't load and the init as well as onListViewUpdated event doesn't fire so the buttons are not available. I think an older version of the list page was cached somehow, because after I cleared the cache, and then refresh the page and both command sets load. The init and onListViewUpdated events fired for both.

Now just navigating (partial page load) between the 2 lists, I don't see the onListViewUpdated fired. When I select an item, then both command sets fire onListViewUpdated 2 times each.

It seems there are instances when onListViewUpdated should fire and doesn't which makes the behavior odd.

In this I also noted that the nav links I make for the lists behave differently if I make them to the list, as opposed to the AllItems.aspx page. The latter causes partial page render behavior, but the former does a full page load and avoids the issue. /sites/siteName/Lists/ListName/ (full page load) -vs- /sites/siteName/Lists/ListName/AllItems.aspx (partial page load)

[frevds]

@westleyMS @patmill The behaviour is even weirder. If you have internal links in the navigation, the content is merely replaced by the new webparts on the other page and the URL adjusted, without page reload, so far so good. Unfortunately, when the target page contains the very same webparts, the webparts are not being reinitialized, and not even rerendered (even though they might have different properties). In our solution we have a sitepage.aspx which we have multiple times in the navigation, with different query parameters. when clicking the FIRST TIME on the navigation link, the URL changes but nothing else happens (no onInit, no render call). We had to listen to URL changes in order to work around that issue and reinitialize the webpart. This even happens if the target is on a different sub site. Now if you click a SECOND TIME (or on a link that is already the active link in the navigation), the whole page reloads (before our little workaround hack, users practically had to double-click the navigation nodes to make the page refresh). Why the page reloads on second clicks is not really clear to me.

[westleyMS]

@frevds this is outside the scope of the OP (ListViewCommandSet Extensions), you might want to start another issue to track the web part problem.

[frevds]

@westleyMS Yeah, it's a different topic and deserves it's own ticket. However, I feel this is closely related. It both concerns the navigation action and its behaviour of reinitializing SPFx solutions, may they be extensions or webparts (it is probably the same event handler/link processor). It might even be the same issue, if the list control experiences the same issues webparts do and is not properly re-initialized when navigating.

On a sidenote I should also mention that loading a CommandSet extension which is using React for its UI components and then navigating to a SitePage with a SPFx webpart on it that uses React as well, this action causes React to be loaded in another instance and crashes the webpart when the first call to a React hook such as useState executes (React error 321). Only a Page reload helps here. This is a separate issue indeed, but demonstrates how this all falls together due to the refresh-strategy of the page.

[litex1982]

We are having exactly same problem, is there any update?

[netti01]

This has been also an issue for us quite a long time. I am really wondering why this ticket is still under review since 7 month because it makes our lib/list extensions nearly unusable because most of the user first open the homepage of the site collection and than (inline) navigate to one of the lists or libraries.

[SP-Ariel]

Hi! I just wanted to see if there is any activity on this issue? @VesaJuvonen @andrewconnell ? We have solutions that are not working as aspected and it feels bad to make temporary solutions (like location.reload() ). And do you have some idea of what a possible solution could be?

Thanks Ariel Johansson (DQC)