Closed Bug 1767277 Opened 3 years ago Closed 2 years ago

teams invitation is not passed to ms teams app

Categories

(Core :: DOM: Security, defect, P3)

Firefox 101
x86_64
Windows 10
defect

Tracking

()

RESOLVED FIXED
Tracking Status
firefox-esr91 --- unaffected
firefox100 --- unaffected
firefox101 --- unaffected
firefox102 --- fixed
firefox103 --- fixed

People

(Reporter: bernd.wolff, Unassigned)

References

(Regression)

Details

(Keywords: regression, Whiteboard: [domsecurity-backlog1])

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:101.0) Gecko/20100101 Firefox/101.0

Steps to reproduce:

click on a MS Teams invitation link

Actual results:

a browser tab opened, giving me the options of continuing in the browser or downloading the (already installed and open) Teams application

Expected results:

The browser tab should open (as above), Teams should become active with the "join" dialog. As it is now, I cannot use my installed Teams via Firefox Nightly.

The Workaround: copy the invitation hyperlink and paste it into chrome.

Component: Untriaged → DOM: Navigation
OS: Unspecified → Windows 10
Product: Firefox → Core
Hardware: Unspecified → x86_64

hsinyi: Do you know somebody who can test this? I think that this bug is important under the COVID-19 situation because Teams has enough market share that we need to support.

Flags: needinfo?(htsai)

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(Away: ~5/8) from comment #1)

hsinyi: Do you know somebody who can test this? I think that this bug is important under the COVID-19 situation because Teams has enough market share that we need to support.

I can reproduce it only on nightly.
On Firefox release 100 or ESR 91, it works as expected, that is, a popup opened to ask me to choose application to open the link. Once I clicked "choose application", I was able to use the installed app to join a Teams meeting.

Flags: needinfo?(htsai)

Hi Paul,
Do you know what's the difference for our permission handler for the external protocol between Nightly and Releases that cause this nightly-only issue? Thank you.

Flags: needinfo?(pbz)

This isn't an issue with permissions, but the sandbox restrictions we have added in Firefox 102. MS Teams is aware of this issue and they're planning to fix the issue by adding the new sandbox flag for external protocol navigation.
See bug 1735746 and the standards discussion linked there for more details.

Flags: needinfo?(pbz)
Component: DOM: Navigation → DOM: Security

The Workaround: copy the invitation hyperlink and paste it into chrome.

Chrome release or Chrome Canary? The Chrome team has implemented this change as well and actually should end up releasing before us. You should compare Firefox nightly to Chrome Canary. An alternate workaround would be to paste the link into Firefox Release

Paul: is this a wontfix then? Or do you want to leave this open as something to pref-off for Release if Chrome gets cold feet and/or MS doesn't fix teams by time we release?

Severity: -- → S3
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(pbz)
Flags: needinfo?(bernd.wolff)
Priority: -- → P3
Regressed by: 1735746

Let's keep this open until Teams has fixed the issue and both Firefox and Chrome shipped the restriction.
Chrome feature status: https://chromestatus.com/feature/5680742077038592

Chrome shipped it as planned/annonced on M103.
There was a devtool warning for M100, M101, M102. This should start affecting canary users right now on Chrome too.

Microsoft team confirmed they started using "allow-top-navigation-to-custom-protocols":
https://github.com/whatwg/html/issues/2191#issuecomment-1113853296
but the change will be released only "during May".

Set release status flags based on info from the regressing bug 1735746

Has Regression Range: --- → yes
Flags: needinfo?(bernd.wolff)
Whiteboard: [domsecurity-backlog1]

:pbz in comment 9 you set 101 to unaffected? Can you confirm since the regressor was released in 101

Confirmed! The regressor is set incorrectly. I've set it to the actual "shipping" bug now.

Flags: needinfo?(pbz)
Regressed by: 1766828
No longer regressed by: 1735746

Breaking Teams invite links sounds like a pretty bad regression for an ESR release which targets enterprise deployments. Paul,can we get this bug assigned and fixed before we ship 102? Thanks

Flags: needinfo?(pbz)

There is no fix to be done from our side. Microsoft Teams has to be updated. See discussion here: https://github.com/whatwg/html/issues/2191#issuecomment-1113853296
It's also broken other browsers, e.g. in Chrome canary currently.

This bug is to keep track of the MS teams breakage and deploy an intervention if necessary. With the current timeline and given that it's broken in Chrome among other browsers to I don't think we need to intervene though.

Flags: needinfo?(pbz)

Set release status flags based on info from the regressing bug 1766828

(In reply to Paul Zühlcke [:pbz] from comment #13)

There is no fix to be done from our side. Microsoft Teams has to be updated. See discussion here: https://github.com/whatwg/html/issues/2191#issuecomment-1113853296
It's also broken other browsers, e.g. in Chrome canary currently.

The ticket above was closed and there is a mention that the change would be deployed in the Teams May release. Can we verify that this is now working in Firefox?

Flags: needinfo?(pbz)

It worked again just now; I let Teams check for updates and restarted it - it is a bit too quiet about its updates for my taste - and the behaviour was as expected with Nightly 103a1. The usual teams web page appears, but the open Teams application is detected and switches to the "join meeting" screen.

Thanks Bernd for the confirmation!

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED

Thanks for checking! Glad to see Microsoft fixed it.

Flags: needinfo?(pbz)
You need to log in before you can comment on or make changes to this bug.