SharePoint pageload suddenly breaks when using `List` and/or `RootFolder` querystrings

[martinlingstuyl]

Target SharePoint environment

SharePoint Online

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

not applicable

Developer environment

None

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

Describe the bug / error

I'm seeing very odd problems when loading pages today.

For example: I'm having a very basis empty page here:

If I add the querystring ?List=43355f7d-c021-4317-9d05-92cece2a1553 (With some random GUID), the page loads badly:

If I add the querystring ?List=someirrelevantvalue&RootFolder=/sites/hr, the page breaks with a message saying it cant find items.

If I add the querystrings ?List=c71dde57-82e9-4210-b856-c5347e63f298&RootFolder=/sites/hr/documents which are referring to an actual document library on another site, the page crashes in another way: saying it cant get a property Title from an undefined object.

This is all quite strange. It seems Microsoft has implemented some new behavior around these two query parameters. Or it's just one code path that now suddenly breaks.

But on our end this breaks a customer solution, because we use NewFormUrl's on content types to redirect to customized creation pages, on which these parameters are added by SharePoint and then the page breaks, blocking people from creating stuff.

Is there someone who recognises this? It's behavior across tenants.

Steps to reproduce

Just append ?List=<some-guid>&RootFolder=/sites/site-url to the URL of your page. (just after .aspx

Expected behavior

It should not crash...

[Ashlesha-MSFT]

Hello @martinlingstuyl,
Thank you for bringing this issue to our attention. We will look into it and get back to you shortly.

[martinlingstuyl]

Awesome, thanks!

[Ashlesha-MSFT]

@martinlingstuyl,
Could you please provide some insights or sample code that you are trying to run?

[martinlingstuyl]

Ok, so essentially the problem is as follows:

In our SharePoint sites we’re using a well-known way to extend SharePoint: Instead of using the default Document Set forms, we’re redirecting users to a SharePoint page on a central site with a customized form. We do this by configuring the NewFormUrl property on DocumentSet content types to the value `/sites/somesite/SitePages/some-page.aspx”.
So when people select a content type to create a documentset, they’re redirected to another page on another site.

What SharePoint does with such redirects, is it adds a couple of Query Parameters relating to the source library:

• List
• Source
• ContentTypeId
• RootFolder

The problem occurs because of the List and RootFolder parameters. They now break the loading of the page. We cannot work around this because we cannot influence SharePoint there. It will automatically add the parameters when redirecting the user.

Note: This used to work fine the last few years, It only started breaking yesterday

It’s very easy to reproduce this issue in any location. Just go to any site page on a tenant and add the following to the URL:
?List=<some-existing-list-id>&RootFolder=<server-relative-url-to-that-list>

The following example triggers the same problem on my dev tenant:

https://blimped.sharepoint.com/sites/HR/?List=87919562-5837-4180-b78b-918754dfda88&RootFolder=/sites/Thedirectors/Shared%20Documents

The following URL triggers a slightly different error, in this case I referenced a list from the same site:

https://blimped.sharepoint.com/sites/HR/?List=c71dde57-82e9-4210-b856-c5347e63f298&RootFolder=/sites/HR/Shared%20Documents

[martinlingstuyl]

A small but maybe important detail that I left out:
When updating the NewFormUrl property, what we actually do is set it to the value

/sites/somesite/SitePages/some-page.aspx?List=%26RootFolder=

So with empty List and RootFolder params. I'm not sure what the history is here, but it was apparently necessary to get it to work.

Be that as it may, even if I remove those params and just set NewFormUrl to /sites/somesite/SitePages/some-page.aspx, SharePoint still adds List and RootFolder, and it will still break the pageload.

[martinlingstuyl]

Do you have an update on this @Ashlesha-MSFT? Someone brought to my attention that we probably configured the NewFormUrl in this way (With empty parameters: /sites/somesite/SitePages/some-page.aspx?List=%26RootFolder=) because it always broke pages. That seems to make sense.

Something did change though, as that workaround is apparently no longer working. The encoding in the URL is probably being evaluated slightly differently now, and SharePoint is now reading the List and RootFolder query params that SharePoint added when redirecting the user.

[Ashlesha-MSFT]

@martinlingstuyl,
We have also found same behavior.
Its good that with this parameter /sites/somesite/SitePages/some-page.aspx?List=%26RootFolder= its working
but with this parameter /sites/HR/?List=c71dde57-82e9-4210-b856-c5347e63f298&RootFolder=/sites/HR/Shared%20Documents getting error

We have logged this as a bug, and our engineering team will share their insights on this.
Thank you for your patience!

[martinlingstuyl]

Ok, thats awesome.

Just an additional note for clarity. Using /sites/somesite/SitePages/some-page.aspx?List=%26RootFolder= in a NewFormUrl, means SharePoint would redirect to /sites/somesite/SitePages/some-page.aspx?List=%26RootFolder=&List=c71dde57-82e9-4210-b856-c5347e63f298&RootFolder=/sites/HR/Shared%20Documents&ContentTypeId=SomeContentTypeId&Source=SomeSource

In other words: it would still add the List and RootFolder (and additional params) based on the library where you are. This used to work, and now it breaks page load.