Bugzilla

So there is definitely some kind of race condition with iframe loading here. If I log in, then open a new tab directly to `https://outlook.uni-polster.de/ecp/Organize/AutomaticReplies.slab?showhelp=false` (the iframe for the autoreply UI without the outer bits), then Chrome loads the default text for the rich text editor widgets containing the user's autoreplies, but Firefox ends up with both being empty iframes with none of that markup.

In Chrome, I see that the markup that's meant to be in those frames includes the string `divtagdefaultwrapper`, which only occurs in the base markup in this code in the HTML:
```
                Sys.Application.add_init(function() {
                    $create(AutomaticRepliesProperties, {
                        "Bindings": /* snip a bunch of stuff */
                        "JsonResults": "{\"__type\":\"AutoReplyConfigurationResults:ECP\", /* snip, includes divtagdefaultwrapper */]}",
                    }, null, {
                       /* snip more */
                    }, $get("ResultPanePlaceHolder_ctl00_ctl02_ctl01_AutomaticReplies"));
                });```
```

And if I place a breakpoint on that `add_init` call, both browsers are running it, and the delay introduced by me having to click to resume from that point also "un-breaks" the situation on Firefox, implicating iframe loading differences/race conditions.

Note that they are not actually setting any iframe `src`/`srcdoc`, they are simply altering the default empty HTML markup of the iframe (as given by about:blank) and setting its body via innerHTML to the `JSONResults` above.  After some diggging around I found that ultimately this happens in `https://outlook.uni-polster.de/ecp/15.0.1497.18/scripts/richtexteditor.js` in:
```
  OwaEditor.Dom.Element.prototype.set_InnerHtml = function (n) {
    do if (n == null || n === undefined) throw new Error('Assert fail [' + '.\\dom/element.js' + ':' + 419 + ']: argument ' + 'sHTML' + ' can\'t be null or undefined');
    while (0);
    do if (n !== null && n !== undefined && String.isInstance != undefined && !String.isInstance(n)) throw new Error('Assert fail [' + '.\\dom/element.js' + ':' + 420 + ']: argument ' + 'sHTML' + ' is not of type ' + 'String');
    while (0);
    this._get_DomNode().innerHTML = n
  };
```

But if I log the node using a conditional logpoint with `n.indexOf('divtagdefaultwrapper')>=0` then I see that while there is a `body` element being set to contain the expected text, by the time I inspect that node it's stale and no longer in the document, with its replacement being a freshly-empty `body` element. This isn't happening on Chrome, leading me to believe either our iframe loading code is replacing the document after they've edited it, or there is something else in their code triggering the same kind of result.

Would we expect the the `about:blank` document to be replaced with a new document, even if it has no src/srcdoc? If so, could we maybe carry over any innerHTML that might have been set before, treating it as though it's a de-facto srcdoc?

So there is definitely some kind of race condition with iframe loading here. If I log in, then open a new tab directly to `https://outlook.uni-polster.de/ecp/Organize/AutomaticReplies.slab?showhelp=false` (the iframe for the autoreply UI without the outer bits), then Chrome loads the default text for the rich text editor widgets containing the user's autoreplies, but Firefox ends up with both being empty iframes with none of that markup.

In Chrome, I see that the markup that's meant to be in those frames includes the string `divtagdefaultwrapper`, which only occurs in the base markup in this code in the HTML:
```
                Sys.Application.add_init(function() {
                    $create(AutomaticRepliesProperties, {
                        "Bindings": /* snip a bunch of stuff */
                        "JsonResults": "{\"__type\":\"AutoReplyConfigurationResults:ECP\", /* snip, includes divtagdefaultwrapper */]}",
                    }, null, {
                       /* snip more */
                    }, $get("ResultPanePlaceHolder_ctl00_ctl02_ctl01_AutomaticReplies"));
                });```
```

And if I place a breakpoint on that `add_init` call, both browsers are running it, and the delay introduced by me having to click to resume from that breakpoint also "un-breaks" the situation on Firefox, implicating possible iframe loading differences/race conditions.

Note that they are not actually setting any iframe `src`/`srcdoc`, they are simply altering the default empty HTML markup of the iframe (as given by about:blank) and setting its body via innerHTML to the `JSONResults` above.  After some diggging around I found that ultimately this happens in `https://outlook.uni-polster.de/ecp/15.0.1497.18/scripts/richtexteditor.js` in:
```
  OwaEditor.Dom.Element.prototype.set_InnerHtml = function (n) {
    do if (n == null || n === undefined) throw new Error('Assert fail [' + '.\\dom/element.js' + ':' + 419 + ']: argument ' + 'sHTML' + ' can\'t be null or undefined');
    while (0);
    do if (n !== null && n !== undefined && String.isInstance != undefined && !String.isInstance(n)) throw new Error('Assert fail [' + '.\\dom/element.js' + ':' + 420 + ']: argument ' + 'sHTML' + ' is not of type ' + 'String');
    while (0);
    this._get_DomNode().innerHTML = n
  };
```

But if I log the node using a conditional logpoint with `n.indexOf('divtagdefaultwrapper')>=0` then I see that while there is a `body` element being set to contain the expected text, by the time I inspect that node it's stale and no longer in the document, with its replacement being a freshly-empty `body` element. This isn't happening on Chrome, leading me to believe either our iframe loading code is replacing the document after they've edited it, or there is something else in their code triggering the same kind of result.

Would we expect the the `about:blank` document to be replaced with a new document, even if it has no src/srcdoc? If so, could we maybe carry over any innerHTML that might have been set before, treating it as though it's a de-facto srcdoc?

So there is definitely some kind of race condition with iframe loading here. If I log in, then open a new tab directly to `https://outlook.uni-polster.de/ecp/Organize/AutomaticReplies.slab?showhelp=false` (the iframe for the autoreply UI without the outer bits), then Chrome loads the default text for the rich text editor widgets containing the user's autoreplies, but Firefox ends up with both being empty iframes with none of that markup.

In Chrome, I see that the markup that's meant to be in those frames includes the string `divtagdefaultwrapper`, which only occurs in the base markup in this code in the HTML:
```
                Sys.Application.add_init(function() {
                    $create(AutomaticRepliesProperties, {
                        "Bindings": /* snip a bunch of stuff */
                        "JsonResults": "{\"__type\":\"AutoReplyConfigurationResults:ECP\", /* snip, includes divtagdefaultwrapper */]}",
                    }, null, {
                       /* snip more */
                    }, $get("ResultPanePlaceHolder_ctl00_ctl02_ctl01_AutomaticReplies"));
                });```
```

And if I place a breakpoint on that `add_init` call, both browsers are running it, and the delay introduced by me having to click to resume from that breakpoint also "un-breaks" the situation on Firefox, implicating possible iframe loading differences/race conditions.

Note that they are not actually setting any iframe `src`/`srcdoc`, they are simply altering the default empty HTML markup of the iframe (as given by about:blank) and setting its body via innerHTML to the `JSONResults` above.  After some diggging around I found that ultimately this happens in `https://outlook.uni-polster.de/ecp/15.0.1497.18/scripts/richtexteditor.js` in:
```
  OwaEditor.Dom.Element.prototype.set_InnerHtml = function (n) {
    do if (n == null || n === undefined) throw new Error('Assert fail [' + '.\\dom/element.js' + ':' + 419 + ']: argument ' + 'sHTML' + ' can\'t be null or undefined');
    while (0);
    do if (n !== null && n !== undefined && String.isInstance != undefined && !String.isInstance(n)) throw new Error('Assert fail [' + '.\\dom/element.js' + ':' + 420 + ']: argument ' + 'sHTML' + ' is not of type ' + 'String');
    while (0);
    this._get_DomNode().innerHTML = n
  };
```

But if I log the node using a conditional logpoint with `n.indexOf('divtagdefaultwrapper')>=0` then I see that while there is a `body` element being set to contain the expected text, by the time I change to the inspector to study that node it's stale and no longer in the document, with its replacement being a freshly-empty `body` element. This isn't happening on Chrome, leading me to believe either our iframe loading code is replacing the document after they've changed its innerHTML , or there is something else in their code triggering the same kind of result.

Would we expect the the `about:blank` document to be replaced with a new document, even if it has no src/srcdoc? If so, could we maybe carry over any innerHTML that might have been set before, treating it as though it's a de-facto srcdoc?

So there is definitely some kind of race condition with iframe loading here. If I log in, then open a new tab directly to `https://outlook.uni-polster.de/ecp/Organize/AutomaticReplies.slab?showhelp=false` (the iframe for the autoreply UI without the outer bits), then Chrome loads the default text for the rich text editor widgets containing the user's autoreplies, but Firefox ends up with both being empty iframes with none of that markup.

In Chrome, I see that the markup that's meant to be in those frames includes the string `divtagdefaultwrapper`, which only occurs in the base markup in this code in the HTML:
```
                Sys.Application.add_init(function() {
                    $create(AutomaticRepliesProperties, {
                        "Bindings": /* snip a bunch of stuff */
                        "JsonResults": "{\"__type\":\"AutoReplyConfigurationResults:ECP\", /* snip, includes divtagdefaultwrapper */]}",
                    }, null, {
                       /* snip more */
                    }, $get("ResultPanePlaceHolder_ctl00_ctl02_ctl01_AutomaticReplies"));
                });```
```

And if I place a breakpoint on that `add_init` call, both browsers are running it, and the delay introduced by me having to click to resume from that breakpoint also "un-breaks" the situation on Firefox, implicating possible iframe loading differences/race conditions.

Note that they are not actually setting any iframe `src`/`srcdoc`, they are simply altering the default empty HTML markup of the iframe (as given by about:blank) and setting its body via innerHTML to the `JSONResults` above.  After some diggging around I found that ultimately this happens in `https://outlook.uni-polster.de/ecp/15.0.1497.18/scripts/richtexteditor.js` in:
```
  OwaEditor.Dom.Element.prototype.set_InnerHtml = function (n) {
    do if (n == null || n === undefined) throw new Error('Assert fail [' + '.\\dom/element.js' + ':' + 419 + ']: argument ' + 'sHTML' + ' can\'t be null or undefined');
    while (0);
    do if (n !== null && n !== undefined && String.isInstance != undefined && !String.isInstance(n)) throw new Error('Assert fail [' + '.\\dom/element.js' + ':' + 420 + ']: argument ' + 'sHTML' + ' is not of type ' + 'String');
    while (0);
    this._get_DomNode().innerHTML = n
  };
```

But if I log the node using a conditional logpoint with `n.indexOf('divtagdefaultwrapper')>=0` then I see that while there is a `body` element being set to contain the expected text, by the time I change to the inspector to study that node it's stale and no longer in the document, with its replacement being a freshly-empty `body` element. This isn't happening on Chrome, leading me to believe either our iframe loading code is replacing the document after they've changed its innerHTML , or there is something else in their code triggering the same kind of result.

Would we expect the initial `about:blank` document to be replaced with a new document, even if it has no src/srcdoc? If so, could we maybe carry over any innerHTML that might have been set before, treating it as though it's a de-facto srcdoc?