Partial page load across site collections (Modern team sites

[raymondlittle100]

Category

• Question
• Typo
• Bug
• Additional article idea

Expected or Desired Behavior

When moving between site collections the page context is refreshed and application customizers are re-loaded with new site details. This used to be the behavior until a couple of weeks ago.

Observed Behavior

Until recently this worked as expected but now when you navigate between pages in different site collections you get a partial page load and any application customizers are not re-loaded.

Steps to Reproduce

Below shows a page with an application customizer which passes the current site from the context to a react component. On first load the current site is correct but after clicking a link to a different team site the page is partially refreshed and the application customizer is not re-loaded. This may be by design but it not how this used to work until a couple of weeks ago and I can find nothing from MS describing this change

Original page load

Component details after clicking link

[tdwhite0]

What you need to do is hook into the navigatedEvent of the app customizer. You can do this in the onInit.
this.context.application.navigatedEvent.add(this, () => { // update your control })

Another thing I have found is that if you use the url of the page you are on from the browser window.location to make any calls inside webparts you will find that the partial navigation causes their js to run before the url is actually updated. So you should always pass the context around and never read from window.location.

[raymondlittle100]

You can use this but the documentation from Microsoft still suggests you use the changedEvent, see documentation below.

This approach worked fine until Microsoft changed the partial page loading to work across site collections whereas previous it was only within the one site collection. All I'm trying to do, and have been for the last few weeks, is get a clear position from them around what is the expected behavior. Its frustrating because all they have to do is say yes its expected or its not. If it is expected here is the correct approach for registering your customizer but there has been nothing

https://docs.microsoft.com/en-us/sharepoint/dev/spfx/extensions/get-started/using-page-placeholder-with-extensions

[tdwhite0]

@raymondlittle100 I agree the partial navigation feature is broken. I am trying to debug issues with it right now in fact. I have the issue where when the page does the partial navigation to a page on a different site collection, it seems to reload components two or more times and causes all their async logic to run multiple times.

[raymondlittle100]

@tdwhite0 Thanks for the response good to know its not just me. When i was testing using the changedEvent customizer event my React render methods weren't event getting hit so it was as if the customizer wasn't getting re-loaded.

Slightly disappointed on the lack of response on this one

[tdwhite0]

@VesaJuvonen did a recent update for this go out that enabled partial navigation between site collections recently? I recently started experiencing some weird issues and that might explain it.

[raymondlittle100]

@tdwhite0 there was a recent change to the customizer events for things like navigating to search application pages and back to ensure the customizer was reloaded but that was a month or two ago. This seemed to start a few weeks ago and I can't find anything to say if its expected or not hence this bug.

[tdwhite0]

@raymondlittle100 We also had something that seems related: We rendered a tags with target="_blank" to get them to open in new tabs, which just recently broke because SP started taking them over and doing partial navigation.

[RichG82]

@tdwhite0 Thanks for the workaround. I am experiencing the same thing with regard to window.location. It seems that there is a lot of unexpected behavior when doing a partial navigation even through normal HTML links (missing title sometimes, tooltips text breaking)

@raymondlittle100 same here. App customizers not running again on a partial page navigation is happening for me too.

I wish we could get a little more traction on this issue.

[raymondlittle100]

@tdwhite0 if you're tags are links you can disable the partial page rendering by adding data-interception="off".

My guess is MS had some code which looks for all links ending with .aspx which used to look for only links pointing to the current site collection and when once of these were hit only reload the content area. This seems to be have been expanded so its not only links in the same team site but any team site.

[tdwhite0]

I started a new issue for my specific case: #2023

[raymondlittle100]

Anything on this?

[rmillener]

@raymondlittle100 thanks for the data-interception="off" tip. Our solution was much more convoluted.

Ours is working in Chrome with a this.context.application.navigatedEvent callback but has stopped working in IE11. In IE the customiser (I assume correctly??) disposes and disappears from the page.

This has been absolutely catastrophic for our deployment. I'm surprised this isn't getting more attention.

[raymondlittle100]

@VesaJuvonen any ideas on this?

[marcDeSantis]

I am also having this same issue, and glad to know I'm not crazy. We are seeing this with a topbar navigation menu built using AngularJS. As you navigate between site collections, it will often throw the browser back to the originating site collection when navigating through secondary collections.

We just released our intranet on May 30th, and it was working fine up until about 2 weeks ago.

I opened a Premier Support ticket, and they are investigating. Has anybody else done so?

[marcDeSantis]

@raymondlittle100 can you explain the data-interception tag? Does that just get added as an attribute of the anchor tag?

@tdwhite0 do you have an example of how to get the window location from the context?

[tdwhite0]

@marcDeSantis It looks like there is a top level routing interceptor that on every click will determine where your link is going and attempt to do a partial navigation on it. For example this will intercept any click on an tag, which is why target="_blank" stopped working on those. However if you set data-interception="off" on the element, it will get ignored and do the old behavior.

For getting the url I make sure to always use the passed in this.context.pageContext.web.absoluteUrl instead of reading it out of window.location.

[raymondlittle100]

SharePoint seems by default to intercept any link pointing to the target tenant and only do a partial page load. This used to be only the current site collection and seems to be where the change has been.

By adding this data attribute to any link it stops the partial page load and does a full refresh

[marcDeSantis]

This data-interception attribute is undocumented, I assume?

[raymondlittle100]

It is supposed because it's what Microsoft do to links set via content editing which are flagged as open in new tab

[marcDeSantis]

I have verified that data-interception="off" has also fixed my issue. Am still curious what Microsoft's recommendation is here, and whether they will take these application extensions into account before making breaking changes down the road.

[raymondlittle100]

Glad to hear it. It's frustrating at the lack of progress or comments

[rmillener]

If its any consolation it appears that the OOTB quick launch is also affected as per #2095

The simplest case is:

1. Create two modern Team Sites
2. Add a link from one to the other to the quick launch
3. Click the link
4. Site navigates but the quick launch stays the same

@marcDeSantis did your premier support ticket get anywhere?

[raymondlittle100]

@rmillener thanks for the update. I'l subscribed to that issue as well in case it gets a response. This has been open for 18 days and nothing whereas others have at least been tagged.

@VesaJuvonen any change of an update?

[marcDeSantis]

@marcDeSantis did your premier support ticket get anywhere?

Nope. I told them that the data-interception workaround was working for me, so they recommended putting in a suggested change to the docs, and mentioned that they cannot guarantee the functionality of customizations 😞

[VesaJuvonen]

We do apologize for the delay on this but are actively working on getting this fixed. This is clearly a bug which we need to get the address on our side.

[raymondlittle100]

Thanks. Appreciate the update

[raymondlittle100]

@rmillener is this still working for you I still get the error?

[rmillener]

@raymondlittle100 no - we've stuck with data-interception. The Quick Launch fix seems to be unrelated.

[raymondlittle100]

@VesaJuvonen any more details on this?

[MarcoSimon]

@VesaJuvonen is there any news on this? I'm still getting this bug!

[petercarson]

@VesaJuvonen also keenly interested in this issue. We have a client about to launch a modern Intranet that this is a blocker for.

[marcDeSantis]

Another side effect of this bug just recently came to my attention. I am not sure if it has always been an issue, or was recently introduced.

Event Web Part Issue
When clicking "Add Event" on the Event Web Part within a page that uses the Application Customizer, the browser navigates to a new URL /_layouts/15/Event.aspx?ListGuid=<GUID>&Mode=Edit

Now, once you click on the Event creation form, the URL jumps back to the root Site Collection. When you click on "Create Event", an error is thrown indicating This link is not valid. Check the link and try again.

@VesaJuvonen today is the 6 month anniversary of this issue. Can we please get an update so that we can understand what we are supposed to do? This is extremely frustrating.

[westleyMS]

@marcDeSantis What are you doing in your OnInit() for your extension? If your extension is not aware of the partial page loads, make sure in OnInit() to only register for the event, for placeholders-
this.context.placeholderProvider.changedEvent.add(this, this._renderPlaceHolders);
for script extensions-
this.context.application.navigatedEvent.add(this, this._runExtension);

There is an issue where these events fire more than once, but that is almost fixed, and you can add code to de-bounce the event. See #1871

[marcDeSantis]

Yes - I am using the changedEvent:

  public onInit(): Promise<void> {
    // Added to handle possible changes on the existence of placeholders.
    this.context.placeholderProvider.changedEvent.add(this, this.renderTopbar)

    this.renderTopbar()
    return Promise.resolve<void>()
  }

[patmill]

Sorry - let me summarize what is happening behind the scenes, what you should be hooked into, and then you can say if your behaviour is different.

First - partial navigation is a whole lot faster, so we would prefer to have everything working correctly, and not messing with the data-interception property.
Second - The goal for extensions is to be loaded once, and kept "alive" for as long as possible. OnInit is called when the extension is loaded (onDispose when it is unloaded). If you have the same extension on multiple site collections / lists / etc. then the design is that onInit is not called when you do a partial navigate between them. This keeps them working fast.

If you look closely, the OnChange notification is hooked up to the placeholderProvider. If the placeholders change (which placeholders exist on the current page, if they are visible or not, etc.) then this event will fire. It shouldn't fire on a navigation event, unless the target of the navigation has different placeholders.

To capture navigate events, you'll want to hook into the navigatedEvent, as @westleyMS writes. There is a bug (fixed and rolling out) where the navigated event would fire multiple times. It should only fire once per navigation event.

Given this information, let me know if things aren't working. Thanks.

[msft-github-bot]

This issue has been automatically marked as stale because it has marked as requiring author feedback but has not had any activity for 7 days. It will be closed if no further activity occurs within next 7 days of this comment. Thank you for your contributions to SharePoint Developer activities.

[marcDeSantis]

I created a scaled down AppCustomizer and sent it to @westleyMS.

[raymondlittle100]

I'm not at the same organisation so am no longer in a position to test in the same way.

[VelinGeorgiev]

@patmill, @westleyMS , I still have issues with that event. I can tweak the code to make it work for me, but they are still there.

The good news is that it fires every time, but here are the three things still an issue for me:

• OnInit of the customizer fires 2 times. There seem to be two instances of my customizer class instead of one.
• this.context.application.navigatedEvent.add sometimes fires 2 times instead of 1.
• this.context.application.navigatedEvent.add does not fire after navigated when page is not cached in IndexedDB, but before.

I will explain in details bellow with the hope that it will help @patmill, but also the community to workaround that for now.

My SPFx version is 1.7.0
The assembly I have on my tenant is the following

Issue N1 - OnInit of the app customizer fires two times. There seem to be two instances of my app customzier class instantiated from the internal SharePoint redux single page application router SharePoint team is building.

I have my app customizer installed only once for the communication site

, but when I add console log on the onInit method of the app costomizer, the onInit is being called twice and NOT from the same instance of the class. There seem to be two app customizer classes running simultaneously for some reason.

The problem with that is that when I subscribe to this.context.application.navigatedEvent.add from onInit, I will subscribe twice if I do not put extra checks to prevent that.

Issue N2 - this.context.application.navigatedEvent.add sometimes fires twice or four times in total if onInit fires twice as well and I've subscribed from there

Here is what happens on the GIF. The this.context.application.navigatedEvent.add fires once, waits for some moments and fires again. Combined with the fact that onInit fires twice, I get navigatedEvent function fired 4 times.

Issue N3 - this.context.application.navigatedEvent.add does not fire after navigated when page is not cached in IndexedDB.

So the description of the navigatedEvent says that is fires after navigated, but it is wrong in specific cases

I noticed that the navigatedEvent fires relatively after page load only when the page is fetched from the client (IndexedDB). If the Microsoft router has to fetch the page from the server, then the navigatedEvent event is fired before the page transition.

3 Tweaks to make it work

Here are the 3 tweaks I had to make in my code so that event fires only once and after the page has loaded. Of-course would be great if I do not have to do that in future.

Here is my code to make it work:

export default class CustomizerLifecycleEventsApplicationCustomizer
  extends BaseApplicationCustomizer<ICustomizerLifecycleEventsApplicationCustomizerProperties> {

  @override
  public onInit(): Promise<void> {

    console.log(`LCEVENT:onInit=${window.location.href}`);

    if (!(window as any).isNavigatedEventSubscribed) {

      this.context.application.navigatedEvent.add(this, this.logNavigatedEvent);

      (window as any).isNavigatedEventSubscribed = true;
    }

    return Promise.resolve();
  }

  @override
  public onDispose(): Promise<void> {

    console.log(`LCEVENT:onDispose=${window.location.href}`);

    this.context.application.navigatedEvent.remove(this, this.logNavigatedEvent);

    (window as any).isNavigatedEventSubscribed = false;
    (window as any).currentPage = '';

    return Promise.resolve();
  }

  public logNavigatedEvent(args: SPEventArgs): void {

    setTimeout(() => {

      if ((window as any).currentPage !== window.location.href) {

        // REGISTER PAGE VIEW HERE >>>
        console.log(`LCEVENT:navigatedEvent=${window.location.href}`);

        (window as any).currentPage = window.location.href;
      }
    }, 3000);
  }
}

So you can see some ugly stuff happening, but this is the way to make it work.

• Issue N1. Subscribing twice is solved by having window.isNavigatedEventSubscribed flag to indicate that a subscription is already set before.
• Issue N2. Firing twice navigatedEvent is solved by having another window.currentPage flag to indicate that this is actually the same navigatedEvent and we do not have to do anything.
• Issue N3. Having setTimeout for 3000 milliseconds is likely to fix the timing issues and ensure that my code will start executing after the new page is loaded by the client router. I can increase or decrease this time.

[westleyMS]

the double firing event has been resolved. My tenant was fixed, and that rollout should be complete by today.

[Waseemnaseem]

Good pro

[andrewconnell]

Appears this issue is fixed from this comment... if not, we can reopen the issue.

[tknaller]

Apperantly partial page loads are now also happening when switching from classic view to modern view...when this happens (not always, some links are not intercepted like page contents) the application customizer doesn't get loaded at all (no onInit trigger)

apparently SP thinks that the placeholders have been there before the navigate event even though it was a classic experience before and the placeholders have never been initialized...

[msft-github-bot]

Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues