EditContext: Would it be useful to have an activeEditContext property on document?

[snianu]

This question was raised in this thread and we want to see what others think about this scenario.

[snianu]

We have been trying out different scenarios to test if the script re-entrancy would cause any side effects in EditContext or not. There is one test case where we had issues in how the EditContext was created inside an event handler which was created in a different realm than where the event got fired. Ex:

const child = document.createElement("iframe");
document.body.appendChild(child);
const childDocument = child.contentDocument;
const textarea = childDocument.createElement('textarea');
childDocument.body.appendChild(textarea);
textarea.addEventListener("focusin", e => {
    childDocument.childEditContext = new EditContext()
    childDocument.childEditContext.focus();
    childDocument.childEditContext.addEventListener("textupdate", e => {
      console.log("iframe textupdate event fired");
      child.remove();
    });
childDocument.childEditContext.addEventListener("textformatupdate", e => {
     console.log("iframe textformatupdate event fired");
    });
  });
textarea.focus();

In this scenario, the EditContext is being created on focusin event. This focusin event handler is defined in the context of the parent document so when this event is fired, the EditContext gets initialized and stored in the parent document instead of the contentDocument where it is supposed to be initialized. This leads EditContext to not fire any textupdate/textformatupdate events in the iframe when the user starts a composition inside the iframe. It does fire those events when the user starts the composition outside the iframe.
Based on this scenario we are proposing 3 potential solutions to this problem:

1. Add an activeEditContext property in the document where the author wants the EditContext to be initialized. This solution requires the web authors to explicitly set the activeEditContext property in the document(also have to check which one is active/inactive) along with managing the focus and blur calls if the author has created multiple EditContexts in multiple documents which also leads to lot of confusion.
2. Pass the document in the EditContext constructor. This is the solution we would like to pursue as it doesn't have the overhead of managing any properties on the document (active/inactive).
3. Restrict the web authors to not allow this kind of initialization. This solution is definitely not the ideal and clean solution as the scenario that we mentioned above is a very common pattern used on the web.
   Please let us know your thoughts on this proposal.

[yosinch]

Could you add examples for proposal 1 and 2?
How about EditContext.isActive property?

[snianu]

For#1 We could have a property in the document like document.activeEditContext which is set to the focused EditContext. document.activeEditContext = new EditContext() or have multiple EditContexts and set this property to point to the active one const editContext = new EditContext(); document.activeEditContext = editContext;

For#2 const editContext = new EditContext(document); When editContext.focus() is called, the document in the editContext will be used to set the active EditContext if the document is the active document and fire events to this EditContext later when there is a composition event.
@BoCupp-Microsoft @gked if you want to add more info

[travisleithead]

I like the idea of proceeding with your 2nd option. @snianu want to take a stab at an update for this?

[snianu]

@alexkeng FYI.

[travisleithead]

This issue was transferred to the Edit-context repo: w3c/edit-context#4