Sp-dev-docs: SPFX Placeholder/Header (Application Extension) - Events bug?

[warren-genpoint]

Hi Guys,

I think this is a bug, I am use a SPFX extension to populate the topheader with a menu. It works a treat, but I have a weird issue happening in that in a certain instance the topheader content will not render out, the DOM is empty <div data-sp-placeholder="Top"></div>

Category

• [ ] Question
• [ ] Typo
• [x] Bug
• [ ] Additional article idea

Expected or Desired Behavior

The topheader renders my content.

Observed Behavior

The topheader is empty in the DOM if you go to the new events webpart "see all" view. Also if you navigate back to a modern page, on first load, the topheader contents wont render.

Steps to Reproduce

Create a spfx extension for SPO to render contents in <div data-sp-placeholder="Top"></div>

1. Deploy the extension.
2. On a modern page, where you see you header being rendered, insert the new events webpart,
3. Publish/Save page
4. Click on "See All" for the events webpart
5. The topheader is not rendered.
6. Go back to home, your topheader is not rendered either (on first load), hitting f5 fixes the issue.

I am not sure why, but it seems to only be affecting this webparts view.

Here is a screenshot of my page, working. if I interact with the Events webpart, my troubles starts.

[moyali]

Hello @warren-genpoint,

Please make sure you're using this.context.placeholderProvider.changedEvent to make sure you render placeholders on any placeholder changes on the page including in-place navigations i.e. navigations that do not reload the page. You can do this in onInit() method. For more info, please see this tutorial: https://docs.microsoft.com/en-us/sharepoint/dev/spfx/extensions/get-started/using-page-placeholder-with-extensions

If that does not resolve the issue, please share your extension code here.

Thanks

[pdemro]

@moyali The suggested fix does not solve the issue.

I have created a repository which demonstrates: https://github.com/pdemro/spfx_placeholder_bug_sample

[pdemro]

I have confirmed this is still an issue with SPFx 1.4 and updated the bug repo with this version https://github.com/pdemro/spfx_placeholder_bug_sample

[pdemro]

Here is an animation demonstrating the issue. Trying absolutely anything to try to get this moving forward. Extensions disappearing during normal navigation of an out-of-box communication site

@VesaJuvonen

[warren-genpoint]

Yep @pdemro that is EXACTLY the problem. Thanks for the effort with the animation.

[VesaJuvonen]

thx Phillip, for pinging around this issue. This is clearly an issue, which we'll need to address asap to get the application customizer as a usable solution. I'll test the repro and get this moving internally. Thanks for the great visual presentation of the issue, which helps in reproducing the issue on our side.

[waldekmastykarz]

There are two issues here.

First, there is an issue in the code.

https://github.com/pdemro/spfx_placeholder_bug_sample/blob/be3e72f621d6efc417c0cc1bfe26f4e4715b6166/spfx_1-4-x/spfx-1-4-x/src/extensions/helloWorld/HelloWorldApplicationCustomizer.ts#L49-L65

If you look at it, the whole block with setting the placeholder's content is executed only when there is no reference to the placeholder, which happens only the first time when the extension executes. This guarantees, that the whole block is executed only once and the contents of the placeholder are set only once, but when you navigate to another page/view, it's not the whole page reloading. Instead, a part of the page's DOM is being rebuilt. Because the extension still holds a reference to the placeholder, the code block isn't executed and the contents are not set.

Instead the code should look something like this:

  private renderTop() {
    // Handling the top placeholder
    const topPlaceholder =
      this.context.placeholderProvider.tryCreateContent(
        PlaceholderName.Top,
        { onDispose: this._onDispose });

    // The extension should not assume that the expected placeholder is available.
    if (!topPlaceholder) {
      console.error('The expected placeholder (Top) was not found.');
      return;
    }

    if (topPlaceholder.domElement) {
      topPlaceholder.domElement.innerHTML = `Hello World spfx1.4 1.0.0.0`
    }
  }

Another issue in the code is, that there are three event handlers defined in code and the event handler is also being called immediately:

https://github.com/pdemro/spfx_placeholder_bug_sample/blob/be3e72f621d6efc417c0cc1bfe26f4e4715b6166/spfx_1-4-x/spfx-1-4-x/src/extensions/helloWorld/HelloWorldApplicationCustomizer.ts#L35-L39

As a result, if you'd run the code I just mentioned, the contents of the placeholder will be set 4 times. Instead, you should associate the event handler only to the navigated event, and remove the other 3 calls:

https://github.com/pdemro/spfx_placeholder_bug_sample/blob/be3e72f621d6efc417c0cc1bfe26f4e4715b6166/spfx_1-4-x/spfx-1-4-x/src/extensions/helloWorld/HelloWorldApplicationCustomizer.ts#L36

Finally, there also seems to be an issue in the SharePoint Framework, where the navigated event is triggered too early. If you setup a debugger in the event handler associated with the navigated event and try to navigate from one page to another you will see the following flow:

• page A
• click to navigate to page B (navigation starts, page A still in browser)
• navigated event triggered, event handler in the extension executed
• new content in the placeholder set
• page B rendered in browser
• contents of the placeholder reset

Hope this helps

[pdemro]

@waldekmastykarz Thank you very much for your thorough analysis. I have updated the demo project with your recommendations for 1 and 2.

For 1, there is probably some opportunity to improve the tutorial documentation to with your recommendations - https://github.com/SharePoint/sp-dev-docs/blob/master/docs/spfx/extensions/get-started/using-page-placeholder-with-extensions.md

@VesaJuvonen looking forward to a response to 3

[warren-genpoint]

Hi Guys,

The same behavior is observed when doing a search, with the top right search bar. The top banner disappears.

Sigh....

[moyali]

Thanks for reporting the issue and the details.

We are aware of the issue and the corresponding team have been tracking the fix.
The issue is that the application destroys the div for the placeholder and does not register the new one as a placeholder with the framework after an in-place navigation.

Assigning to @mpasarin for further follow up

[warren-genpoint]

@moyali Thanks for the feedback, I wasn't aware it happened with search also. When I originally discovered this bug it only appeared as I described above. I was doing some further development in my project again and that is when I saw the same behavior with search, thought I would just add :-)
Hope it gets patched soon, users are looking at me funny when the menu I am inserting in the placeholder disappears :-)

[pdemro]

1263 #1254 #1265

[eschrader]

I usually use onInit rather than render because of this. The only issue is I have jquery to hide the OOTB "Feedback" button on SP with my extension, but it only hides the button when the extension is first loaded (oninit). navigating to subsequent pages the Feedback button is redrawn and appears but my oninit jquery is not executed, leaving the Feedback button on subsequent pages.

[dpalfery]

Bump. This has been an issue for about 4 months now. This is an active bug in 3 customer instances. Is there an ETA? we have seen at least one revision of the framework sense this was posted....

[pdemro]

I recall last week @VesaJuvonen mentioned there has been some progress on the server side. No word on a timeline however

[BraunJonathan]

Same here, it's been a few months now and still no fix...
With the new new search page on modern sites, the header does not show up, neither does it return when closing the search page...
This is a really annoying issue, is there an ETA for a fix?

[guillaume-kizilian]

Works on IE11 o_O (it took some times to realise)
Just on "See All" though, when searching it still disappear and won't reappear when going back.

(right on time for prod release :+1: )

[nsksaisaravana]

Please give an ETA for this and somehow we are managing our clients.

[salvation06]

This issue not only affects the application customizers like the header/footer, it also affects SPFX webparts that are rendered on the page if a user is performing in-place navigation within SharePoint.

Through a little console debugging I was able to add a window.location.href check, and what I observed was that when you click a link within SharePoint such as the Site Navigation links, the url page location is NOT changing. In whatever way the page redirect is being performed, essentially the browser is not recognizing that the user is now on a new page. A simple F5 refresh will allow the web parts to load and also will return the correct window.location.href value.

I have also noticed during mytesting that the React Content Query Editor web part and the Modern Script Editor web part which are part of the sp-dev-fx-webparts solution both seem to work with in-place navigation or even when using the back button. However, many other SPFX open source web parts do not (a lot of the SPFX-40-fantastics web parts and many of the sp-dev-fx-webparts like JSDisplayList).

So perhaps the MS team should take a look at what differentiates the working SPFX web parts from the others and then make this a standard part of the scaffolding?

[eschrader]

I noticed if my web part has an iframe to an outside website the home url goes home but then redirects the user back to the page they were on. I ended up using a JavaScript new window for the iframe instead to work around it. Lots of funky navigation with spfx but understandable. Home it all gets fixed or documented

Sent via the Samsung Galaxy S7 active, an AT&T 4G LTE smartphone

-------- Original message --------
From: salvation06 [e-mail]
Date: 4/6/18 7:42 AM (GMT-08:00)
To: SharePoint/sp-dev-docs [e-mail]
Cc: Eric Schrader [e-mail], Comment [e-mail]
Subject: Re: [SharePoint/sp-dev-docs] SPFX Placeholder/Header (Application Extension) - Events bug? (#1042)

This issue not only affects the application customizers like the header/footer, it also affects SPFX webparts that are rendered on the page if a user is performing in-place navigation within SharePoint.

Through a little console debugging I was able to add a window.location.href check, and what I observed was that when you click a link within SharePoint such as the Site Navigation links, the url page location is NOT changing. In whatever way the page redirect is being performed, essentially the browser is not recognizing that the user is now on a new page. A simple F5 refresh will allow the web parts to load and also will return the correct window.location.href value.

I have also noticed during mytesting that the React Content Query Editor web part and the Modern Script Editor web part which are part of the sp-dev-fx-webparts solution both seem to work with in-place navigation or even when using the back button. However, many other SPFX open source web parts do not (a lot of the SPFX-40-fantastics web parts and many of the sp-dev-fx-webparts like JSDisplayList).

So perhaps the MS team should take a look at what differentiates the working SPFX web parts from the others and then make this a standard part of the scaffolding?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/SharePoint/sp-dev-docs/issues/1042#issuecomment-379274635, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ARme5dur43-mVTHs5JfW0hb2lJ_9DZzVks5tl369gaJpZM4QbdkV.

[Rainson12]

i have the same issue. Im rendering my navigation on the event as waldek supposed:
this.context.application.navigatedEvent.add(this, this.initStuff);

As soon as i navigate to the search and click the browser back button my framework extension is "removed".
The event is being fired and also the innerHtml of the (in the event) created placeholder is being set but the actual rendering does never happen. It seems like the placeholder thats being created by

const _topPlaceholder = this.context.placeholderProvider.tryCreateContent( PlaceholderName.Top, { onDispose: this._onDispose });

is not attached to the actual page.

[Rainson12]

I did a quick fix to at least let the application load when returning from the search:
when setting the content of the placeholder ive did a little check wether the placeholder exists and if not it waits for it to be created and then attached the topPlaceholder to the REAL placeholder "holder"

if (document.querySelectorAll("[data-sp-placeholder]").length == 0)
{
var interval = setInterval(function() {
if (document.querySelectorAll("[data-sp-placeholder]").length == 0)
return;
clearInterval(interval);
if(_topPlaceholder.domElement.parentNode != document.querySelectorAll("[data-sp-placeholder]")[0])
document.querySelectorAll("[data-sp-placeholder]")[0].appendChild(_topPlaceholder.domElement)
_topPlaceholder.domElement.innerHTML = content;
}, 1); // let SP create the placeholder
}
else{
_topPlaceholder.domElement.innerHTML = content;
}

[guillaume-kizilian]

@rainson12 have you tried not using const for placeholder?

[VesaJuvonen]

The issue has been finally fixed. Due series of unfortunate events, this took much longer than expected but is finally now fixed and shipped to production. Fix has been completed on the server side, so no changes needed on the SPFx package.

[nsksaisaravana]

Finally !!! Thanks a lot.

[raymondlittle100]

Has this been fully rolled out or is it still in the process of rolling out?

I have noticed the top placeholder still isn't populated on the events page, might be by design similar to search results page. In addition when returning from the events page the behavior is still the same and the top customizer isn't loaded.

In most cases if I navigate to the search results page and return the customizer is visible after existing from the search page but if I visit the events page and then go to the search page and come out again the placeholders are blank. All the issues seem to be around the events

My customizer was created a while ago so does the event registration may be need updated, see below.

@override
public onInit():Promise {
return super.onInit().then(_ => {

    console.log('ApplicationCustomizer onInit() called...');
    this.context.placeholderProvider.changedEvent.add(this, this._renderPlaceHolders);        
    this._renderPlaceHolders();

    return Promise.resolve();
  });      
}

private _renderPlaceHolders():void {

  if(!this.topPlaceholder) {
    this.topPlaceholder = this.context.placeholderProvider.tryCreateContent(
      PlaceholderName.Top, 
    {
      onDispose: this._onDispose
    });
  }

  if(!this.topPlaceholder) {
    console.log('Can\'t find top placeholder');
    return;
  }

  if(this.topPlaceholder.domElement) {

//Do processing
}
}

[warren-genpoint]

How long would the update take to reach all tenants?

[VesaJuvonen]

Sorry for indicating that this is fully fixed slightly too early.... or to be precise, fix is done and it's getting currently rolled out across the world. Everything should be updated by end of Tuesday 24th of April. If that's not the case, please do open a new issue, so that your response or findings will not get lost. Thx.

[PooLP]

Hi,
On my tenant, it's not deployed or the bugs it's not totally resolved.

[warren-genpoint]

@PooLP its working fine now on my tenant. Maybe do a hard refresh (ctrl+f5)? I didnt have to do that it just works.

@VesaJuvonen The issue still presents itself if you use the modern search. placeholder (Top) disappears :-( Is this by design?

[PooLP]

@warren-genpoint : Yes, I cleared my cache. The problem described is about search page on modern sites for me (hubsite, communication and team site)

[warren-genpoint]

@PooLP ah, okay, yes, thats still not working for me either. Waiting on some feedback hopefully from @VesaJuvonen

[PooLP]

For more explain, the bugs are exactly the ones describe by @BraunJonathan

[PooLP]

Hi,
@VesaJuvonen you have any news for this bugs (especially the bug the banner that does not appear in search page) ? I need an answer for our customers.

I have another steps to Reproduce a another bugs :

• Load the search page directly (no by a search query, load directly URL of search page ex:https:///sites//_layouts/15/search.aspx/siteall?q=lorem)
• Click on Exit search
• The header do not appear on anothers pages

Thanks.

[adambu]

I am still seeing this problem with the Events.aspx page on multiple tenants. Please see: https://github.com/SharePoint/sp-dev-docs/issues/2198. Since the issue happens on the reference example project, I think any discussion about the quality of this or that specific implementation is kind of beside the point. If we update the reference example project and it works, then customers can use the guidance approach.

[sps-smith]

waldekmastykarz explanation of the issue and recommended solution worked for me. Thanks

[kasgit]

Hi,

This issue seems to happen again for some tenants.

Steps to reproduce:

1. Deploy an extension to a site.
2. Navigate to task list or any classic page.
3. Navigate back to any list or library(with modern page).
4. The extension won't load.

A few observations:

1. It only happens in the tenants where the new Microsoft Search [Featured ID: 34273] enhancement has been rolled out. The search bar appears on the top of the page in these tenants.
2. If we refresh the page, the extension loads.
3. Wherever a partial load seems to happen, it doesn't load. And the navigation loads in the home page even if navigate from a classic page(Full load).

[SinghGurd]

@VesaJuvonen I can second what @kasgit has reported that navigatedEvent doesn't fire when navigating between different libraries

[dhruvp29]

@VesaJuvonen I am facing the issue while navigating between the folders. My problem is similar to #1254 .
I have raised new ticket. Please check #4557

[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