Can't remove/add symbols inside the editor in IFrame (Firefox 57)

[AndreyMitsyk]

monaco-editor version: 0.10.1
Browser: Firefox 57.0 (64-bit)
OS: Windows 10 64-bit

Re-pro steps:

1. Open editor inside the IFrame in Firefox, e.g. playground https://microsoft.github.io/monaco-editor/playground.html
2. Change content inside editor
3. Set focus outside the Monaco editor
4. Set focus back inside the editor and try to remove/add something

Expected:
User able to edit content.

Actual:
User can't edit content. By the pressing backspace tab Firefox will navigate you to the previous page.

[AndreyMitsyk]

Workaround for Firefox 57: set focus manually for the iframe element with Monaco editor on click:

JQuery version for playground:

var frame = $("#runner"); 
frame.contents().on('click', () => {
    var activeElement = $(document.activeElement);
    if(!activeElement.is(frame)) {
        activeElement.blur(); 
        frame.focus();
    }
});

[mokevnin]

We have the same problem. @AndreyMitsyk thanks for the workaround!

[TheRealPiotrP]

@alexandrudima is this an issue you may be able to pursue in the near future? We're seeing the same issue on https://try.dot.net. The workaround proposed by @AndreyMitsyk will require our hosting sites [e.g. docs.microsoft.com and others] to implement the workaround, which means we'll need to ask all of our partners to implement a new feature. We'd much rather take a fix in the service itself such that our partners get the fix for free. If, however, you won't be able to get to this for some time then we'll need to kick off an effort with our partners to get customers unblocked. Any guidance will be much appreciated.

[alexdima]

Interestingly, I cannot reproduce on Firefox on OSX, so it might be a FF+Windows specific issue

[jonsequitur]

@alexandrudima, the issue doesn't repro on the https://try.dot.net landing page but it does repro in the try.dot.net runners for example in docs.microsoft.com: https://docs.microsoft.com/en-us/dotnet/csharp/quick-starts/numbers-in-csharp#step-2. I can repro that on OS X and Linux.

The important difference is that the Run button on try.dot.net's landing page is inside the iframe with the Monaco editor, whereas in our common embedded scenarios, the Run button is outside the iframe and Monaco is controlled programmatically by the host page using postMessage. Clicking Run there moves the focus out of the iframe and triggers the bug.

I can also see a variant of this bug on OS X and Windows (but did not check Linux) in the Monaco playground you linked at the top of this issue.

[rebornix]

The behavior of active element in iframe in Firefox changed somehow, and IMHO it's a bug of Firefox. The workflow is like

1. Monaco Editor opens in iframe
2. User clicks on it, we get the click event, draw the blinking cursor and focus on a hidden textarea
3. User clicks somewhere outside the iframe, iframe loses focus
4. In other browsers, like Chrome, or old Firefox I believe, the active element in that iframe is no longer that textarea
5. User click on Monaco editor in iframe, we draw the blinking cursor, we find that the active element is not the textarea, we call textarea.focus()

Right now, even though users move the focus out of the iframe, Firefox kind of keeps the state, and when users click on Monaco in iframe again, we find the textarea is still the active element, so our shortcut code path doesn't do textarea.focus() 1, 2.

This logic is as expected, as if the textarea is the active element, we don't need to do anything. However, in this case, the textarea no longer receives any keyboard event. Even though Firefox tells us it's the one who has focus.

Fix

If we set textarea.focus() every time, Firefox is sane again. @alexandrudima any side effect of doing so? I saw some comments about perf there so not sure.

Workaround

@TheRealPiotrP @jonsequitur gentlemen, you can add below script to ensure a focused element is really focused again in Firefox.

document.onclick = function () {
	if (document.activeElement) {
		document.activeElement.focus();
	}
};

[alexdima]

Thanks a lot @rebornix !

Yes, it is a perf issue I noticed. Calling textarea.focus() every time causes (or used to cause) a synchronous browser layout. We could call textarea.focus() every time when running in Firefox and inside an iframe (window.parent !== window) and let Firefox pay the perf hit...

[rebornix]

Fixed in the way @alexandrudima suggested. Will ship this fix with next release.

[jonsequitur]

@rebornix Thanks for the workaround suggestion. It doesn't seem to work for me, unfortunately.

[TheRealPiotrP]

@rebornix @alexandrudima since we're having trouble with the workaround, is the next release with the fix coming soon? Otherwise, can we explore some other workarounds together?

[TheRealPiotrP]

@rebornix did you intend for the workaround to be implemented in the hosting page or the hosted page?

[rebornix]

@TheRealPiotrP ideally it just needs to be put next to monaco code, which is inside the iframe. Can you provide some info about how I run try.dot.net bits locally, with which I can troubleshoot.

Speaking of next version of Monaco, we are going to release next week but we still need to make sure that our fix gets rid of the issue you are running into.

[TheRealPiotrP]

@rebornix I'll have @colombod reach out to you with repro.