Teams, goedit, Roblox, GoToMeeting and Steam "hidden iframe" links in Firefox 78.0.1 don’t work
Categories
(Firefox :: File Handling, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr68 | --- | unaffected |
firefox-esr78 | 78+ | verified disabled |
firefox78 | + | verified disabled |
firefox79 | + | verified disabled |
firefox80 | + | verified |
People
(Reporter: yannick.le-jeune, Assigned: Gijs)
References
(Regression)
Details
(Keywords: enterprise, regression)
Attachments
(2 files)
47 bytes,
text/x-phabricator-request
|
jcristau
:
approval-mozilla-release+
jcristau
:
approval-mozilla-esr78+
|
Details | Review |
47 bytes,
text/x-phabricator-request
|
RyanVM
:
approval-mozilla-beta+
|
Details | Review |
User Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 13_5_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1.1 Mobile/15E148 Safari/604.1
Steps to reproduce:
Upgrade from FF 68.9.0ESR to 78.0.1ESR.
Actual results:
MS Teams links (received by mail and opened by FF) aren’t opened on Teams Application since we do the upgrade.
Expected results:
Worked fine on previous version.
And impossible to rollback to FF 68.9.0 without create a new user FF profile.
Same here, introduced after the change from v77 to v78 of Firefox (now running on 78.0.1).
FWIW: when opening the developer console on the website that used to trigger the launch of the Teams Application, the link to manually launch the Teams Application works again. Maybe that helps to identify the culprit.
Same here in my client's 2012 13.3" MacBook Pro with updated mac OS Mojave v10.14.6, https://www.usc.edu/office365, and Firefox v78.0.1. Please fix this soon for v78.0.2?
Reporter | ||
Updated•5 years ago
|
My Windows 10 (1903) users have the same problem with Teams since upgrading to 78.0.1. It also seems to happen when clicking a Citrix Receiver link from a website.
Both can be worked around by opening the dev tools with F12 before clicking the link. Another workaround is installing the extension uBlock Origin which make the links work again as before. Might work with other extensions as well, but I haven't tried.
Comment 5•5 years ago
|
||
This Bug also affects links for sending mails in Microsoft Dynamics 365 CRM - when then link is clicked nothing happens. The issue can be worked around by clicking F12, too.
We first noticed this on our Remote Desktop servers with Windows Server 2019, with latest Windows updates and Firefox 78.0.1esr (64-Bit). I was able to reproduce this on my working machine with Windows 10 2004 and Firefox 78.0.1esr (64-Bit). Downgrading to Firefox 68.10.0esr (64-Bit) resolves the problem, sadly this isn't an option for our servers...
Can you please test if the problem disappears, when you open the inspector window? You can open the inspector by right-click and "inspect element". Then try again and see if it works.
BTW, we have a similar problem with opening an application via protocol handler and iframe: https://bugzilla.mozilla.org/show_bug.cgi?id=1651014
Comment 7•5 years ago
|
||
From my point of view as ordinary person, using the F12 key and opening the inspector by right click leads to the same result.
@Stefanie: Its not about the way you open the inspector window, you should testdrive if the problem with an open inspector window still exist?
Comment 9•5 years ago
|
||
In my original comment I wrote "The issue can be worked around by clicking F12, too.", so I believed the question is already completely answered.
To make things clear: With MS CRM opening the inspector by F12 works around the issue and the link opens normally in this case.
Comment 10•5 years ago
|
||
I tested all nightly versions on macOS and found out that this issues was introduced between the following builds:
- OK https://download-origin.cdn.mozilla.net/pub/firefox/nightly/2020/06/2020-06-02-21-53-59-mozilla-central/
- FAIL https://download-origin.cdn.mozilla.net/pub/firefox/nightly/2020/06/2020-06-03-09-29-05-mozilla-central/
This seems tightly related to the following bugs:
Comment 11•5 years ago
|
||
Toshi, do you know if we did anything wrt opening external applications in 78?
Comment 12•5 years ago
|
||
Julien, we somehow expect this to be related to iframes. For example we are opening an iframe to trigger the protocol handler, so we somehow expect this to be the possible root cause.
If you we can help to investigate this issue further give us a short note, so we can support you guys. Unfortunately the error does not appear when the inspector is open, which make this issue hard to investigate on our side.
Comment 13•5 years ago
|
||
The regression range from comment 10 points at this pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f3a829091fef&tochange=bf162b065e1feaa64d6df95bc55ee8a894312d34
Maybe bug 1606797?
Comment 14•5 years ago
|
||
yes, when narrowing down the issue with mozregression i'm also ending up on bug 1606797...
Updated•5 years ago
|
Assignee | ||
Comment 15•5 years ago
|
||
Is there somewhere public where I can reproduce this problem?
And can any of the folks reproducing it try switching security.allow_disjointed_external_uri_loads
to true
in about:config, restart Firefox, and check if the problem still occurs?
Assignee | ||
Comment 16•5 years ago
|
||
(In reply to :Gijs (he/him) from comment #15)
Is there somewhere public where I can reproduce this problem?
And can any of the folks reproducing it try switching
security.allow_disjointed_external_uri_loads
totrue
in about:config, restart Firefox, and check if the problem still occurs?
Needinfo for this; the pref appears to fix bug 1651395, bug 1651014, and bug 1651174, but I have no idea how to test "Teams Application" (or what that even is), and there appear to be no steps in this bug. :philipp, you mentioned you ran mozregression, can you check the pref and/or elaborate?
:jcristau, have we built 78.0.2 yet, and if not, can we take a patch to flip that pref?
Comment 17•5 years ago
|
||
(In reply to :Gijs (he/him) from comment #16)
:jcristau, have we built 78.0.2 yet, and if not, can we take a patch to flip that pref?
Not yet, so yeah, we can take that extra pref flip.
Comment 18•5 years ago
|
||
(In reply to :Gijs (he/him) from comment #16)
(In reply to :Gijs (he/him) from comment #15)
Is there somewhere public where I can reproduce this problem?
You can the function in public:
- Go to https://goedit.io -> Online Demo -> Confluence
- create new page by clicking on "Test GoEdit"
- change the page title and save
- now you can hover over a file link like "Benefits of GoEdit.docx" and click on it
- this should result in opening an external application
Assignee | ||
Comment 19•5 years ago
|
||
(In reply to Andre U from comment #18)
(In reply to :Gijs (he/him) from comment #16)
(In reply to :Gijs (he/him) from comment #15)
Is there somewhere public where I can reproduce this problem?
You can the function in public:
- Go to https://goedit.io -> Online Demo -> Confluence
- create new page by clicking on "Test GoEdit"
- change the page title and save
- now you can hover over a file link like "Benefits of GoEdit.docx" and click on it
- this should result in opening an external application
This doesn't appear to have anything to do with "MS Teams" from comment #0. It may have the same regression cause, but the regressing bug changed a number of things, and so what I'm trying to establish is whether the same pref is sufficient to solve the specific issue reported in comment #0. We've already established in the other bug that the scenario you describe is fixed by the pref.
Comment 20•5 years ago
|
||
yes, setting security.allow_disjointed_external_uri_loads
to true
fixes the problem for me (even without a restart of the browser).
Comment 21•5 years ago
|
||
I tested the config change (security.allow_disjointed_external_uri_loads) on Firefox 78.0.1 (64-Bit), Windows 10 on an affected machine and it does helped! Thanks!! Teams loads again without opening DevTools F12.
Comment 22•5 years ago
|
||
Updated•5 years ago
|
Comment 23•5 years ago
|
||
The patch is for 78 so leaving this unassigned for further investigation on trunk.
Updated•5 years ago
|
Assignee | ||
Comment 24•5 years ago
|
||
Hopefully phab will leave this alone now.
Assignee | ||
Updated•5 years ago
|
Updated•5 years ago
|
Comment 25•5 years ago
|
||
Comment on attachment 9162203 [details]
Bug 1650162 - Turn security.allow_disjointed_external_uri_loads back on to fix regressions opening external applications. r?Gijs
We got confirmation this fixes the regression, so let's get this pref flip in 78.0.2.
Updated•5 years ago
|
Comment 26•5 years ago
|
||
uplift |
for 78.0.2:
https://hg.mozilla.org/releases/mozilla-release/rev/e56adbbfe01c2443bae35e3d6f34867e36c3828e
for 78.0.2esr:
https://hg.mozilla.org/releases/mozilla-esr78/rev/6e1145ecb9914c071b0066b3422ff33464196190
Leaving esr78 status set to affected so we graft the patch to the default branch (for 78.1esr) later.
Updated•5 years ago
|
Reporter | ||
Comment 27•5 years ago
|
||
(In reply to :Gijs (he/him) from comment #15)
Is there somewhere public where I can reproduce this problem?
And can any of the folks reproducing it try switching
security.allow_disjointed_external_uri_loads
totrue
in about:config, restart Firefox, and check if the problem still occurs?
Thx a lot. It works when we switch this parameter to "True". And we can deploy it by a pref.js in GPO. Will it be fixed in 78.0.2 ?
Assignee | ||
Comment 28•5 years ago
|
||
(In reply to Yannick Le Jeune from comment #27)
Thx a lot. It works when we switch this parameter to "True". And we can deploy it by a pref.js in GPO. Will it be fixed in 78.0.2 ?
78.0.2 will set the new pref to true by default in order to fix this bug.
I'm not sure how your infrastructure for GPO works and if you can set the pref now and un-set it once 78.0.2 has sufficiently rolled out to your users (at which point it'll be the default so you don't need to set it via GPO) - we will be attempting a "real" fix (ie which keep the pref false
) for 79/80, and it'd be a shame if your users kept the pref set to true
forever.
Comment 29•5 years ago
•
|
||
Reproduced the initial issue using latest Nightly 80.0a1. Verified that using Firefox 78.0.2 and Firefox 78.0.2esr when accessing the url received in outlook will correctly ask to open Teams Microsoft and then the app is opened/call is started across platforms (Windows 10 64bit, macOS 10.15.6 and Ubuntu 18.04 64bit). I also verified that flipping the security.allow_disjointed_external_uri_loads
pref to true
also fixes this in latest Nightly.
Assignee | ||
Updated•5 years ago
|
Comment 30•5 years ago
|
||
bugherder uplift |
Assignee | ||
Comment 32•5 years ago
|
||
OK, I've finally had a chance to sit down and debug this, the root cause is that MS teams (and the other sites with similar issues) load their external-protocol URIs (msteams:<stuff>
in the MS teams case) in a hidden iframe, for which we never bother creating an inner document and window global object, which broke some of the checking code which expected the browsingcontext into which an external URL was loaded to have a window global. Opening devtools "fixes" it because devtools ends up trying to explore the hidden iframe, which forces gecko to initialize the about:blank document in it. I hope to have a patch up soon, though I'll try and also get an automated test together, which might take me a bit more time...
Assignee | ||
Comment 33•5 years ago
|
||
The aim of the code we're modifying here is to block things in one browsingcontext
tree from opening external links in another browsingcontext tree (and causing the
external protocol dialog to show up for that tab/window) -- except if the other
browsingcontext into which something is being loaded is same-origin.
Unfortunately the pre-patch code assumed that it would find currentWindowGlobal
objects for each browsingcontext, and it turns out that's not guaranteed,
especially in the case of hidden iframes, which turn out to be quite commonly
used for external protocol launches.
This patch fixes this by continuing to move towards the root of the browsingcontext
tree even if there's no currentWindowGlobal (though logically speaking, this
should only be necessary for the first iteration of the loop, it seems easier to
just always check this). It also adds a test for this behaviour working.
Updated•5 years ago
|
Comment 35•5 years ago
|
||
Also verified on latest treeherder build from mozilla-esr78 repository that this is no longer an issue for 78.1.0esr across platforms (Windows 10 64bit, macOS 10.15.6 and Ubuntu 18.04 64bit).
Comment 36•5 years ago
|
||
I think it is more accurate to say that the status is disabled in 78 and esr78. Since there is an fix for when the pref is enabled still coming.
Comment 38•5 years ago
|
||
Comment 39•5 years ago
|
||
Backed out for bc failures on browser_protocol_ask_dialog.js.
Failure log: https://treeherder.mozilla.org/logviewer.html#?job_id=309928529&repo=autoland
Backout link: https://hg.mozilla.org/integration/autoland/rev/32bac254e9a8ae5182af35fd1ea388074cb1ea07
Assignee | ||
Updated•5 years ago
|
Comment 40•5 years ago
|
||
Assignee | ||
Comment 41•5 years ago
|
||
Updating some of the tracking flags per earlier comments.
Assignee | ||
Comment 42•5 years ago
|
||
Comment on attachment 9162659 [details]
Bug 1650162 - disjoint external URI loading protection should deal with invisible iframes, r?mattwoodrow
Beta/Release Uplift Approval Request
- User impact if declined: Broken exterrnal protocol requests
- Is this code covered by automated tests?: Yes
- Has the fix been verified in Nightly?: No
- Needs manual test from QE?: Yes
- If yes, steps to reproduce: See some of the duplicate bugs for publicly accessible STR if there's no MS Teams. Someone also provided me with a private msteams: based testcase, please message me if you need access.
- List of other uplifts needed: n/a
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): This is a glorified nullcheck in a loop, and there's an automated test.
It'd be still-lower-risk for this particular issue to ship the pref-flip with 79 -- but continuing to ship with the additional checks turned off has other risks, so on balance I think this fix would be preferable over flipping the pref. The extant code that caused this bug has now lived on beta/nightly for a while (where we didn't flip said pref), and the only issue I'm aware of is this and its dupes, all to do with the same failure mode. In other words, I'm reasonably confident that having this issue fixed by this patch and keeping the pref as it is for 79 is unlikely to turn up new, separate issues that would not be fixed by this patch but would be avoided by flipping the pref as we did on 78.
- String changes made/needed: None
Comment 43•5 years ago
|
||
bugherder |
Comment 44•5 years ago
|
||
Comment on attachment 9162659 [details]
Bug 1650162 - disjoint external URI loading protection should deal with invisible iframes, r?mattwoodrow
Approved for 79.0b9. Thanks for including a test. Hopefully QA can verify this by testing some of the duplicate bugs too.
Comment 45•5 years ago
|
||
bugherder uplift |
Comment 46•5 years ago
|
||
NI myself to uplift the pref flip patch to Beta for 79rc1 per bug 1653541.
Comment 47•5 years ago
|
||
uplift |
Disabled for 79.0 RC1.
https://hg.mozilla.org/releases/mozilla-beta/rev/249a14ce30f0
Updated•5 years ago
|
Comment 48•5 years ago
|
||
Also verified that it is fixed on latest Nightly 80.0a1 and disabled for 79.0 RC1 across platforms (Windows 10 64bit, macOS 10.15 and Ubuntu 18.04 64bit) using Microsoft Teams and also the services from the duplicate bugs: goedit, Roblox, GoToMeeting and Steam.
Updated•5 years ago
|
Updated•6 months ago
|
Description
•