Support iframes (nested browsing contexts) in selection event handling

[acusti]

Fixes #427

dda228b depends on facebook/fbjs#188 to actually work. With the current version of fbjs, the doc argument will be ignored and getActiveElement will execute relative to the global document.

Had some more tests for ReactInputSelection that rely on DOM functionality that jsdom doesn’t yet support. Includes this block, for setSelection, but requires a working getSelection() implementation (see jsdom/jsdom#937):

    it('sets selection offsets on a contentEditable element', () => {
      var node = createAndMountElement('div', null, textValue);
      ReactInputSelection.setSelection(node, {start: 1, end: 10});
      expect(ReactInputSelection.getSelection(node)).toEqual({start: 1, end: 10});
    });

Also, had a suite for getSelectionInformation/restoreSelection for a focused element inside an iframe, but it requires jsdom to have accurate activeElement functionality with iframes. I made a PR to fix that part of jsdom (jsdom/jsdom#1621), so hopefully when that functionality gets added, I can add these tests in:

    it('gets and restores selection for inputs in an iframe that get remounted', () => {
      var iframe = document.createElement('iframe');
      document.body.appendChild(iframe);
      iframe.focus();
      var iframeDoc = iframe.contentDocument;
      var input = document.createElement('input');
      input.value = textValue;
      iframeDoc.body.appendChild(input);
      input.focus();
      input.selectionStart = 1;
      input.selectionEnd = 10;
      var selectionInfo = ReactInputSelection.getSelectionInformation();
      expect(selectionInfo.focusedElem).toBe(input);
      expect(selectionInfo.selectionRange).toEqual({start: 1, end: 10});
      expect(document.activeElement).toBe(iframe);
      expect(iframeDoc.activeElement).toBe(input);

      input.setSelectionRange(0, 0);
      iframeDoc.body.removeChild(input);
      expect(iframeDoc.activeElement).not.toBe(input);
      expect(input.selectionStart).not.toBe(1);
      expect(input.selectionEnd).not.toBe(10);
      iframeDoc.body.appendChild(input);
      ReactInputSelection.restoreSelection(selectionInfo);
      expect(iframeDoc.activeElement).toBe(input);
      expect(input.selectionStart).toBe(1);
      expect(input.selectionEnd).toBe(10);

      document.body.removeChild(iframe);
    });

[acusti]

I created a demo of a simple use case to illustrate the utility of this PR. I then duplicated the demo and have one using the current react and react-dom builds and one using built versions of those files made from this branch.

Without the changes in this branch: http://codepen.io/acusti/pen/kkBpWA?editors=0011
With the changes in this branch: http://codepen.io/acusti/pen/rrpKYZ?editors=0011

[acusti]

One issue that remains is that the selection in the textarea inside the iframe is lost after it gets rerendered with a changed value prop. Not sure if getSelectionInformation/restoreSelection can / should be further modified to apply to any iframes, not just the current focused one (in the demo, when you focus the text input that is outside of the iframe, the iframe is of course no longer the activeElement).

[acusti]

I updated the demo to include logic for maintaining the selectionStart and selectionEnd on the textarea whenever its value gets changed when it doesn’t have focus and it seems to work ok. Visually, you still lose the selection, but when you tab to change focus into the textarea, you get the correct selection back.

[acusti]

I made another demo that only changes the textarea value in the iframe on enter or blur and manually restores selection then focuses the iframe when appropriate (much like ReactInputSelection.restoreSelection).

Without the changes in this branch: http://codepen.io/acusti/pen/EgQxJG?editors=0011
With the changes in this branch + the React PR: http://codepen.io/acusti/pen/qaxBby?editors=0011

Makes me think that if ReactInputSelection.restoreSelection were updated to get and restore selection for all nested browsing contexts it had access to, it would be nice. I could make a build that does that to see how well it works, if that would make sense.

[acusti]

Continuing this ongoing conversation with myself, above I wrote that:

One issue that remains is that the selection in the textarea inside the iframe is lost after it gets rerendered with a changed value prop. Not sure if getSelectionInformation/restoreSelection can / should be further modified to apply to any iframes, not just the current focused one.

I’ve since figured out how focus events work in the browser across browsing contexts and made a new demo that properly restores focus as you go: http://codepen.io/acusti/pen/JRpBWv?editors=0011

It’s seamless and makes for a really nice UX, plus it uses native browser functionality so has full a11y. This made me realize that in order to make ReactInputSelection properly restoreSelection even with iframes being rendered, it should in fact be modified to apply to any iframes, not just the primary focused one. I’ll publish a branch that does that, make a build from it, and use it in the above demo without the custom focus management I added (lines 82 and 111-116) to see how well it works.

[acusti]

The new PR which gets and restores selections for any iframes, not just the primary focused one, is #7936

[acusti]

I’m thinking I should close this in favor of #7936, because that implementation seems more complete to me based on the current behavior of ReactInputSelection, but it’s hard for me to know what people would be interested in without hearing from anyone. Any thoughts, comments, opinions? Should I close this one? Close #7936?

[acusti]

Closing in favor of #11410