SPFx in Teams Mobile no longer loads

[thechriskent]

Target SharePoint environment

SharePoint Online

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

💥 SharePoint Framework

Developer environment

macOS

What browser(s) / client(s) have you tested

• [ ] 💥 Internet Explorer
• [X] 💥 Microsoft Edge
• [ ] 💥 Google Chrome
• [ ] 💥 FireFox
• [ ] 💥 Safari
• [X] mobile (iOS/iPadOS)
• [ ] mobile (Android)
• [ ] not applicable
• [ ] other (enter in the "Additional environment details" area below)

Additional environment details

• New Teams on iOS (reports of same issue happening in Android)
• SPFx 1.19.0

Describe the bug / error

SPFx webparts hosted in teams no longer load in the mobile apps. The issue appears to be the call the teamsJs app context. In the vanilla webpart, this section of code causes the problem:

  private _getEnvironmentMessage(): Promise<string> {
    if (!!this.context.sdks.microsoftTeams) { // running in Teams, office.com or Outlook
      return this.context.sdks.microsoftTeams.teamsJs.app.getContext()
        .then(context => {
          let environmentMessage: string = '';
          switch (context.app.host.name) {
            case 'Office': // running in Office
              environmentMessage = this.context.isServedFromLocalhost ? strings.AppLocalEnvironmentOffice : strings.AppOfficeEnvironment;
              break;
            case 'Outlook': // running in Outlook
              environmentMessage = this.context.isServedFromLocalhost ? strings.AppLocalEnvironmentOutlook : strings.AppOutlookEnvironment;
              break;
            case 'Teams': // running in Teams
            case 'TeamsModern':
              environmentMessage = this.context.isServedFromLocalhost ? strings.AppLocalEnvironmentTeams : strings.AppTeamsTabEnvironment;
              break;
            default:
              environmentMessage = strings.UnknownEnvironment;
          }

          return environmentMessage;
        });
    }

    return Promise.resolve(this.context.isServedFromLocalhost ? strings.AppLocalEnvironmentSharePoint : strings.AppSharePointEnvironment);
  }

Steps to reproduce

1. Generate a standard web part using 1.19.0
2. Deploy to teams (I used a custom manifest)
3. Try to load it on Teams Mobile
4. Witness the never ending loading

Expected behavior

I expected the out of the box webpart to work as it did previously. It still works on desktop without issue, it's specifically within the Teams mobile client that the issue is seen.

The version of TeamsJS is controlled by SharePoint. The SPFx app shows it's using TeamsJS 2.12.0 but this isn't the actual version loaded on the page. This was working with TeamsJS 2.22.0 (last time I checked the version) but it appears the version was just updated to 2.24.0 in the past couple of days. This change is breaking all our stuff.

I have recreated the issue without changing a line of code in the default scaffolded web part which is why I believe the server side change to TeamsJS has caused this issue.

[AJIXuMuK]

@thechriskent - thanks Chris for reporting the issue. Could you please specify what mobile device you are using (Android/iOS and device)

I can't reproduce the issue on my side

[thechriskent]

Hi, Alex! Thanks for looking into this.

I am testing with iOS but we have reports of the same issue happening on Android as well. I generated a web part using 1.19.0 and selected React for the framework. The only line of code I have changed is line 28 where I'm passing the teamsJs.version for the description:

  public render(): void {
    const element: React.ReactElement<IHelloWorldProps> = React.createElement(
      HelloWorld,
      {
        description: this.context.sdks.microsoftTeams?.teamsJs.version || 'Not Teams',
        isDarkTheme: this._isDarkTheme,
        environmentMessage: this._environmentMessage,
        hasTeamsContext: !!this.context.sdks.microsoftTeams,
        userDisplayName: this.context.pageContext.user.displayName
      }
    );

Here it is working as expected within New Teams on the Mac:

Here it is in the neverending placeholder display in the iOS Teams app:

---

Now, if I adjust the _getEnvironmentMessage() method like this:

private _getEnvironmentMessage(): Promise<string> {
    // if (!!this.context.sdks.microsoftTeams) { // running in Teams, office.com or Outlook
    //   console.log('teams version', this.context.sdks.microsoftTeams.teamsJs.version);
    //   return this.context.sdks.microsoftTeams.teamsJs.app.getContext()
    //     .then(context => {
    //       let environmentMessage: string = '';
    //       switch (context.app.host.name) {
    //         case 'Office': // running in Office
    //           environmentMessage = this.context.isServedFromLocalhost ? strings.AppLocalEnvironmentOffice : strings.AppOfficeEnvironment;
    //           break;
    //         case 'Outlook': // running in Outlook
    //           environmentMessage = this.context.isServedFromLocalhost ? strings.AppLocalEnvironmentOutlook : strings.AppOutlookEnvironment;
    //           break;
    //         case 'Teams': // running in Teams
    //         case 'TeamsModern':
    //           environmentMessage = this.context.isServedFromLocalhost ? strings.AppLocalEnvironmentTeams : strings.AppTeamsTabEnvironment;
    //           break;
    //         default:
    //           environmentMessage = strings.UnknownEnvironment;
    //       }

    //       return environmentMessage;
    //     });
    // }

    return Promise.resolve(this.context.isServedFromLocalhost ? strings.AppLocalEnvironmentSharePoint : strings.AppSharePointEnvironment);
  }

Once I redeploy, here is the web part on iOS in the Teams app:

Can you check to see if we have the same version of TeamsJS being handed to us? Thanks

[AJIXuMuK]

@thechriskent I'm testing on Prod so should be on the same version. And double checked that 2.24.0 is used in my case as well. Have you tried on another tenant? Also could you try modifying the code to have catch block and see if any error is presented?

[thechriskent]

Everything works as expected in my dev tenant (teamsJs 2.24.0) and since it's working for you, I'm assuming it's something specific to our corporate tenant. I'd also guess the teamsJs version isn't likely the problem but rather whatever is hot swapping the dependency.

Trying to troubleshoot what the problem is, however, is proving to be super hard. Wrapping the call in a try/catch fixes nothing. Unless I comment out the call to teamsJs.app.getContext() entirely, the bundle does not load. Even if that code is unreachable, just it existing in the project causes the web part to not load in teams mobile (within our tenant).

So, the problem appears to only be affecting my tenant (that we know of). However, the issue showed up in previously working already deployed code, can be recreated with the vanilla setup, and the error is happening before my code even loads. This strongly appears to be a Microsoft issue. Seeing as we are on a few rings ahead of targeted release, I wouldn't be surprised to see this issue start showing up more widely (though I don't know how many SPFx webparts are being surfaced in Teams on mobile). With that in mind, if anyone is aware of any teams/tenant settings that we might have enabled that could cause this, I'm all ears.

Should I open a true support ticket for this one?

---

As an aside, what is the reasoning for how teamsJS is handled compared to other dependencies? This seems super weird that although I have a dependency specified and can test with it, the hot swap nature of it makes our testing invalid, causes issues with mismatched typings, and introduces a dependency we don't actually have control over and can only validate at runtime.

I'm not aware of any other part of SPFx doing that. Who thought this was a good idea?

[Ashlesha-MSFT]

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

[Ashlesha-MSFT]

@thechriskent, For our tenant its working as expected

[Ashlesha-MSFT]

We are closing this issue for now. If the problem persists, feel free to reopen it or open a new one.