1683756 - Microsoft Office and other custom protocol handlers requiring user confirmation are broken when used in `window.open("custom:something").close()`

Status: RESOLVED WONTFIX

(Firefox :: Security, defect)

Description

[Jiacheng Yang]

Attachment: zoom_0.mp4

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36

Steps to reproduce:

In our product, we support using Microsoft Office custom protocol handlers (the scheme: https://docs.microsoft.com/en-us/office/client-developer/office-uri-schemes) to launch Excel/Word directly from our web app. But for version 84.0, this functionality appears broken. When users are trying to do the same thing, the tab is quickly opened and closed.

This problem is not present in Chrome or older versions of FireFox.

Since this is not a ordinary user behavior, I will attach a video for demonstrations.

Actual results:

Excel/Word cannot be launched

Expected results:

Excel/Word can be launched properly.

Comment 1

[Jiacheng Yang]

One possible way to test this could be just using a page with a link using an Office uri scheme I think

Comment 2

[Andrei Purice]

Setting a component for this issue in order to get the dev team involved.
If you feel it's an incorrect one please feel free to change it to a more appropriate one.

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

emilio, is this possibly related to the user activation changes?

Comment 4

[Emilio Cobos Álvarez [:emilio]]

How are you launching the external protocol? Can you let me know how to reproduce this? (an url or what not?)

Thanks

Comment 5

[Emilio Cobos Álvarez [:emilio]]

I don't think this is due to the changes in bug 1679456 because those are in 85, not 84, but happy to dig a bit either way.

I'd be curious if Firefox Beta (85) works though.

Comment 6

[Jiacheng Yang]

Hi, sorry, yesterday was Boxing Day in Canada and I was on vacation.

Right now I do not have an easy example in hands, but I suppose you should be able to reproduce this following: https://self-learning-java-tutorial.blogspot.com/2017/10/office-uri-scheme.html. Please let me know if this is not working for you or not.

At the meantime, I will test with FireFox Beta (85) I think.

Thanks

Comment 7

[Emilio Cobos Álvarez [:emilio]]

(In reply to Jiacheng Yang from comment #6)

Hi, sorry, yesterday was Boxing Day in Canada and I was on vacation.

No worries, totally understandable!

Right now I do not have an easy example in hands, but I suppose you should be able to reproduce this following: https://self-learning-java-tutorial.blogspot.com/2017/10/office-uri-scheme.html. Please let me know if this is not working for you or not.

I tried that example (with the paths changed to point to a local file of course) and it works fine here both in Firefox 84 and Nightly 86.

The way your application tries to open the link is likely relevant. Is it a regular link? A target="_blank" link? window.open()? An iframe? Something else? If window.open() or an iframe, is it done from a click event handler? Also does it reproduce on a clean profile?

If you can come up with a test-case (even if it requires having a particular file in a particular directory or something) it would be amazing so we can get to the bottom of this.

Thanks

Comment 8

[Jiacheng Yang]

Hi, sorry for the late reply, in our current approach, we do something like

window.open(protocol + ':' + (view ? 'ofv' : 'ofe') + '|u|' + sUrl).close();

;however we are currently only use this for FireFox since this code was written many years ago for special handling.

For all other browsers we are using something like

window.location.href = protocol + ':' + (view ? 'ofv' : 'ofe') + '|u|' + sUrl;

And after doing more testing, it seems that the normal approach (the second piece of code) works just fine in newer FireFox, so we probably are just going to discard the old code, which technically should fix our problem.

Thanks for looking into this.

Comment 9

[Emilio Cobos Álvarez [:emilio]]

(In reply to Jiacheng Yang from comment #8)

Hi, sorry for the late reply, in our current approach, we do something like

window.open(protocol + ':' + (view ? 'ofv' : 'ofe') + '|u|' + sUrl).close();

;however we are currently only use this for FireFox since this code was written many years ago for special handling.

For all other browsers we are using something like

window.location.href = protocol + ':' + (view ? 'ofv' : 'ofe') + '|u|' + sUrl;

And after doing more testing, it seems that the normal approach (the second piece of code) works just fine in newer FireFox, so we probably are just going to discard the old code, which technically should fix our problem.

Interesting, that's good to know that you have a workaround and that the special code-path is no longer needed. Curious:

• If you keep the old code, and remove the .close(), does it work?
• If not, can you tell me how the thing is invoked? Is it from a click handler? Something else? Does the result change if you set dom.disable_open_during_load=false in about:config?

Thanks!

Comment 10

[Jiacheng Yang]

Hi,

If remove the .close() code, it does work. But users will be required to close the newly opened empty tab afterwards.

I think it's just an angular service definition (https://docs.angularjs.org/api/ng/type/angular.Module#service).

I am actually not sure what a about:config file is. I am personally a purely server side dev and I asked some client devs but they are not sure either.

Thanks.

Comment 11

[Emilio Cobos Álvarez [:emilio]]

about:config is not a file, it's an "advanced settings" URL that you can access from the browser. But thanks, that's really useful info.

Here's a test-case that worked for me and broke (though it seems to have broken a while ago, actually), at least on nightly:

<!doctype html>
<script>
  function openExternalProtocol() {
    window.open("magnet:foo").close();
  }
</script>
<button onclick="openExternalProtocol()">Do it</button>

The regression range for that is:

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=a76116eb180c3cacdd1cb555d1bc4ac54c9d2f5e&tochange=b4b26ce1c20ec113d9f36f5bd824e95dea4d40cd

So, bug 1606797. Gijs, can you take a look?

Comment 12

[Emilio Cobos Álvarez [:emilio]]

Attachment: testcase

Comment 13

[BugBot [:suhaib / :marco]]

The product::component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.

Comment 14

[:Gijs (he/him)]

There are a lot of confusing factors here. My machines don't have any magnet handlers, nor do they have Office installed, so neither of those work as testcases - they never open anything, even on unaffected builds, or if I remove the .close(). :-\

Switching to mailto successfully opens my local mail client, also on current 85 beta, irrespective of the .close().

So my impression is that the issue is with the case where we try to show a dialog asking the user what application to use. I can reproduce on Windows with a microsoft-edge:https://... url on a clean profile.

The problem is that that dialog has since become tab-modal (bug 1661030). In this case, we open a new tab, we try to open the dialog, and then we close the tab again. I guess, like we do for printing in some circumstances, the attempt to open an external protocol should keep the tab open. But I don't think this is something we can do from the frontend, and in fact I don't recall off-hand how printing and other, similar cases achieve this. Emilio, do you have suggestions?

(Note that it's possible that even then, the code introduced in bug 1606797 is breaking the URL open due to principal checks, but just disabling those checks using the security.allow_disjointed_external_uri_loads pref is insufficient to fix the issue, so it's not just that change...)

Comment 15

[Emilio Cobos Álvarez [:emilio]]

The problem is that that dialog has since become tab-modal (bug 1661030). In this case, we open a new tab, we try to open the dialog, and then we close the tab again. I guess, like we do for printing in some circumstances, the attempt to open an external protocol should keep the tab open. But I don't think this is something we can do from the frontend, and in fact I don't recall off-hand how printing and other, similar cases achieve this. Emilio, do you have suggestions?

For printing, we spawn a nested event loop. So effectively, the call to window.print() doesn't return until printing is done. This happens here.

For this case, we'd need to block the call to window.open I think, which can already happen here IIRC, for e10s at least? So I think at least it could be possible to detect this case and wait on the tab modal before resolving the window open, but it seems somewhat unfortunate.

I think if this doesn't come up again, and given:

• This doesn't seem to work on other browsers either.
• The reporter can fix it by using the same code as other browsers.

This might be ok to WFM / WONTFIX. But that's your call I think.

Comment 16

[:Gijs (he/him)]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #15)

The problem is that that dialog has since become tab-modal (bug 1661030). In this case, we open a new tab, we try to open the dialog, and then we close the tab again. I guess, like we do for printing in some circumstances, the attempt to open an external protocol should keep the tab open. But I don't think this is something we can do from the frontend, and in fact I don't recall off-hand how printing and other, similar cases achieve this. Emilio, do you have suggestions?

For printing, we spawn a nested event loop.

😱

So effectively, the call to window.print() doesn't return until printing is done. This happens here.

For this case, we'd need to block the call to window.open I think, which can already happen here IIRC, for e10s at least? So I think at least it could be possible to detect this case and wait on the tab modal before resolving the window open, but it seems somewhat unfortunate.

I agree.

I think if this doesn't come up again, and given:

• This doesn't seem to work on other browsers either.

Ah, hm. Then I think we'd probably be best off not introducing incompatibility where none exists right now...

• The reporter can fix it by using the same code as other browsers.

This might be ok to WFM / WONTFIX. But that's your call I think.

Well, you assigned yourself. ;-)

But I agree wontfix sounds good here, if our current behaviour is what other browsers do (and this is the first report along these lines that I've seen since the changes went out, which included 78 esr, I think...).