1736570 - Outlook OWA Automatic Replies not working - _event error or broken fields.

Reporter

Description

•

3 years ago

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:93.0) Gecko/20100101 Firefox/93.0

Steps to reproduce:

You log in to the Outlook OWA portal. Then you go to the point -Automtische Reply Send- There you enter the e-mail that should be sent when you are written to

Actual results:

You get the error message:

Client Information

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:93.0) Gecko/20100101 Firefox/93.0
CPU Class: undefined
Platform: Win32
System Language: undefined
User Language: de-DE
CookieEnabled: true

Exception Details

Date: Tue Oct 19 2021 14:36:28 GMT+0200 (Mitteleuropäische Sommerzeit)
Message: TypeError: a._events is undefined
Url: https://outlook.uni-polster.de/ecp/15.0.1497.18/scripts/microsoftajax.js
Line: 5

Call Stack

ErrorHandling.$EM@https://outlook.uni-polster.de/ecp/15.0.1497.18/scripts/common.js:1:172926
ErrorHandling.showUnhandledException@https://outlook.uni-polster.de/ecp/15.0.1497.18/scripts/common.js:1:172011

Dump Event

isTrusted = true
message = TypeError: a._events is undefined
filename = https://outlook.uni-polster.de/ecp/15.0.1497.18/scripts/microsoftajax.js
lineno = 5
colno = 58709
error = TypeError: a._events is undefined
composedPath = function composedPath() {
[native code]

}
stopPropagation = function stopPropagation() {
[native code]
}
stopImmediatePropagation = function stopImmediatePropagation() {
[native code]
}
preventDefault = function preventDefault() {
[native code]
}
initEvent = function initEvent() {
[native code]
}
type = error
target = [object Window]
srcElement = [object Window]
currentTarget = [object Window]
eventPhase = 2
bubbles = true
cancelable = true
returnValue = true
defaultPrevented = false
composed = false
timeStamp = 165576
cancelBubble = false
originalTarget = [object Window]
explicitOriginalTarget = [object Window]
NONE = 0
CAPTURING_PHASE = 1
AT_TARGET = 2
BUBBLING_PHASE = 3
ALT_MASK = 1
CONTROL_MASK = 2
SHIFT_MASK = 4
META_MASK = 8

Detailed Call Stack

Expected results:

The automatic e-mail should have been saved and set.

Pablo

Comment 1

•

3 years ago

Hi,

Can you provide the link you are using to log in to the portal?

is it https://outlook.uni-polster.de ? or https://www.microsoft.com/en-us/microsoft-365/outlook/web-email-login-for-outlook ?

Does this issue occur in the latest nightly version of firefox? Here is a link from where you can download it:
https://www.mozilla.org/en-US/firefox/channel/desktop/

thanks.

Flags: needinfo?(itservice)

itservice

Reporter

Comment 2

•

3 years ago

Hi,
the firefox version iss 93.0 and the link we are using is
https://outlook.uni-polster.de

Flags: needinfo?(itservice)

Pablo

Comment 3

•

3 years ago

set component, not sure if its the correct one.
the site gives me a potential security risk and i have no access to it.

Component: Untriaged → General

Whiteboard: qa-not-reproducible

Mike Kaply [:mkaply]

Comment 4

•

3 years ago

Can you tell me what version of Outlook you are using on the server?

I'm going to try to install a version locally for testing.

Or possibly give me a test account? (I know that's unlikely)

Flags: needinfo?(itservice)

itservice

Reporter

Comment 5

•

3 years ago

Its on a Server with - Windows Server 2012 R2
Outlook Version: 15.0 (Build 1497.2)

Flags: needinfo?(itservice)

itservice

Reporter

Comment 6

•

3 years ago

https://outlook.uni-polster.de/owa/auth/logon.aspx?replaceCurrent=1&url=https%3a%2f%2foutlook.uni-polster.de%2fowa
User: Bug.Zilla@uni-polster.de
Password: Bugzilla

Mike Kaply [:mkaply]

Comment 7

•

3 years ago

The best I can do for a regression window is August 28 of last year I think this covers it:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=56166cae2e26429f4786ad1013adae78189a12e8&tochange=29ba77e279e4346ecf071b81c8fb171115b266d1

This is a bigger issue now because of the new ESR which folks are switching to.

If you have a a response set, the bug is even worse because the fields are unclickable.

Severity: -- → S1

Status: UNCONFIRMED → NEW

tracking-firefox95: --- → ?

tracking-firefox96: --- → ?

Ever confirmed: true

Keywords: regression

Priority: -- → P1

Mike Kaply [:mkaply]

Updated

•

3 years ago

Summary: Outlook OWA Automatic Anser → Outlook OWA Automatic Replies not working - _event error or broken fields.

Mike Kaply [:mkaply]

Comment 8

•

3 years ago

So it definitely was a patch in here:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=56166cae2e26429f4786ad1013adae78189a12e8&tochange=fdf95334aded3175771c724e785fb148f95ed10b

Mike Kaply [:mkaply]

Comment 9

•

3 years ago

I thought it might be bug 1649121 but I tried backing out part 76 (the only one I could) and it didn't fix it on trunk.

I was unable to get any of this revisions building so I could try to bisect exactly what broke it.

Olli/Masayuki, any ideas here?

Flags: needinfo?(masayuki)

Flags: needinfo?(bugs)

Pascal Chevrel:pascalc

Updated

•

3 years ago

status-firefox94: --- → wontfix

status-firefox95: --- → affected

status-firefox96: --- → affected

status-firefox-esr91: --- → affected

tracking-firefox95: ? → +

tracking-firefox96: ? → +

Olli Pettay [:smaug][bugs@pettay.fi]

Comment 10

•

3 years ago

I'm still trying to get those old versions to build. My guess is that Bug 1589102 caused this, since the issue doesn't seem to be about editing.

Hsin-Yi Tsai (she/her) [:hsinyi]

Comment 11

•

3 years ago

•

Edited

(In reply to Mike Kaply [:mkaply] from comment #7)

The best I can do for a regression window is August 28 of last year I think this covers it:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=56166cae2e26429f4786ad1013adae78189a12e8&tochange=29ba77e279e4346ecf071b81c8fb171115b266d1

This is a bigger issue now because of the new ESR which folks are switching to.

If you have a a response set, the bug is even worse because the fields are unclickable.

FWIW, "the fields are unclickable" was randomly reproducible to me, not always reproducible but frequently. I still didn't figure out a reliable STR. I also agree the unclikable issue is even more severe.

Cristian Baica [:cbaica], Release Desktop QA

Comment 12

•

3 years ago

Unfortunately I couldn't narrow it down any better than mkaply did.

The last known good build: 2020-08-28
The first bad build: 2020-08-29
Regression range: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=61ed3192760a3aaef282c089c064fc8dd3890125&tochange=29ba77e279e4346ecf071b81c8fb171115b266d1

One of the things I noticed is that I didn't have any font changes applied to either written text or selected text. Maybe look into any text editing changes done in the patch @mkaply? (that's my best guess).

The unclickable fields issue is indeed quite severe and I think I found out some reliable steps in reproducing it.

Log into the outlook account.
Click on the account settings button and choose 'set automatic replies' option.
Choose 'Send automatic replies' and input some text in the fields.
Click the save button and then the 'OK' button on the received error.
Close Firefox (choose the 'Leave' option if prompted with the unsaved changes modal).
Re-open the browser and login back into the outlook account.
If the prompt to turn off the automatic replies is received choose NOT to turn off the replies (click NO on the prompt).
Click on the account settings button and choose 'set automatic replies' option.

---> The textbox fields are unclickable.

Workaround:

If the prompt to turn off the automatic replies is received, choose Yes to turn off the automatic replies (click Yes on the prompt). Access the 'set automatic replies' section and notice the fields can be edited.
Go to the 'set automatic replies' section, choose the radio button to 'Don't send automatic replies' and click the save button. Click the outlook 'back' arrow and then access the section again. Once the 'Send automatic replies' radio button is selected the fields can be edited again (become active).

Olli Pettay [:smaug][bugs@pettay.fi]

Comment 13

•

3 years ago

I've been trying to get old m-c to build, no luck yet. Even tryserver doesn't give me builds.

Olli Pettay [:smaug][bugs@pettay.fi]

Comment 14

•

3 years ago

Now getting closer with builds.

Olli Pettay [:smaug][bugs@pettay.fi]

Comment 15

•

3 years ago

If the send button triggers errors, only then the textareas become disabled.

And it is Bug 1589102 which causes the error.

Anny, could you take a look? I'll upload instructions how to get the old m-c build in a moment.

Flags: needinfo?(masayuki)

Flags: needinfo?(bugs)

Flags: needinfo?(agakhokidze)

Regressed by: 1589102

BMO Automation

Updated

•

3 years ago

Has Regression Range: --- → yes

Olli Pettay [:smaug][bugs@pettay.fi]

Comment 16

•

3 years ago

•

Edited

Attached file remove an unused variable so that harfbuzz compiles — Details

I needed to apply the patch and then also run the following commands to compile the old m-c
(https://hg.mozilla.org/mozilla-central/rev/e763b6e09a4914247ab86b3600acac8562e6c1d1 I didn't check which of the patches in that bug regressed the behavior).

rustup toolchain install 1.46.0
rustup override set 1.46.0
cargo install --version 0.14.3 cbindgen
export CBINDGEN=~/.cargo/bin/cbindgen

Pascal Chevrel:pascalc

Updated

•

3 years ago

status-firefox95: affected → wontfix

Anny Gakhokidze [:annyG]

Comment 17

•

3 years ago

Because the changes that caused this regression are quite low level, I can't understand how exactly they caused this. It seems that there are two separate issues - first is that we get an error when we try to save the automatic response, and second, is that the text field for the automatic responses later become disabled and we can't type in them. I think that if we figure out what causes the first issue and solve it, the second issue will not be a problem. I will point out that the text fields become enabled once I clear the cookies for the site and login again.

The text fields in question are actually iframes whose location is about:blank. In my original patches, I changed about:blank loads to take place via DocumentChannel, which meant that about:blank pages took a little longer to load. I thought perhaps that's the issue, so I checked out the commit before my changes and added the following change (1) in nsFrameLoader to artificially delay loading of about:blank, but I could not reproduce the issue this way on my mac.

(1)

diff --git a/dom/base/nsFrameLoader.cpp b/dom/base/nsFrameLoader.cpp
index 39a85558280e4..9ad1dace7e1a7 100644
--- a/dom/base/nsFrameLoader.cpp
+++ b/dom/base/nsFrameLoader.cpp
@@ -476,6 +476,7 @@ void nsFrameLoader::LoadFrame(bool aOriginalSrc) {

   bool isSrcdoc = mOwnerContent->IsHTMLElement(nsGkAtoms::iframe) &&
                   mOwnerContent->HasAttr(kNameSpaceID_None, nsGkAtoms::srcdoc);
+  bool isBlank = false;
   if (isSrcdoc) {
     src.AssignLiteral("about:srcdoc");
     principal = mOwnerContent->NodePrincipal();
@@ -494,6 +495,7 @@ void nsFrameLoader::LoadFrame(bool aOriginalSrc) {
                                      nsGkAtoms::_true, eCaseMatters)) {
         return;
       }
+      isBlank = true;
       src.AssignLiteral("about:blank");
       principal = mOwnerContent->NodePrincipal();
       csp = mOwnerContent->GetCsp();
@@ -515,6 +517,12 @@ void nsFrameLoader::LoadFrame(bool aOriginalSrc) {
   if (rv == NS_ERROR_MALFORMED_URI) {
     rv = NS_NewURI(getter_AddRefs(uri), u"about:blank"_ns, encoding, base_uri);
   }
+  if (isBlank) {
+    for (int i = 0; i< 200000; i++) {
+      printf_stderr("i ");
+    }
+    printf_stderr("\n");
+  }

   if (NS_SUCCEEDED(rv)) {
     rv = LoadURI(uri, principal, csp, aOriginalSrc);

Hsin-Yi Tsai (she/her) [:hsinyi]

Comment 18

•

3 years ago

•

Edited

Hi Tom, I asked for some help in webcompat channel to look into the web site code. Karl suggested you may be the person who can help figure out what's happening. :)

Flags: needinfo?(twisniewski)

Thomas Wisniewski [:twisniewski]

Comment 19

•

3 years ago

•

Edited

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?

Flags: needinfo?(twisniewski)

Hsin-Yi Tsai (she/her) [:hsinyi]

Comment 20

•

3 years ago

Henri or Kris may be able to answer the question in comment 19.

Flags: needinfo?(kmaglione+bmo)

Flags: needinfo?(hsivonen)

Kris Maglione [:kmag]

Comment 21

•

3 years ago

(In reply to Thomas Wisniewski [:twisniewski] from comment #19)

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?

It depends on exactly how the about:blank document is loaded. There's an initial implicit about:blank document which is always created instantly when it's needed, and a possible explicit about:blank document, which can be created a number of ways, like setting window.location or the src attribute to "about:blank". That one is the one that would be created by DocumentChannel, and is now asynchronous. I would expect it to replace the contents added to the initial one if there's an explicit about:blank load going on and the content is added to the initial one too early.

Flags: needinfo?(kmaglione+bmo)

Kris Maglione [:kmag]

Comment 22

•

3 years ago

Do you by chance know how the iframe is being created, and if/when "about:blank" is being loaded into it, either via a src attribute or something like a location assignment? My guess is that this is most likely to happen if we dynamically create an iframe with an explicit about:blank load and then immediately modify the DOM of the initial about:blank document.

Flags: needinfo?(twisniewski)

Thomas Wisniewski [:twisniewski]

Comment 23

•

3 years ago

No, I don't know yet, but I'll take a closer look tomorrow. Thanks for the info, it does make me suspect that they're doing something (perhaps unintentionally) to trigger a document replacement.

remove an unused variable so that harfbuzz compiles 3 years ago Olli Pettay [:smaug][bugs@pettay.fi] 1.53 KB, text/plain		Details
Bug 1736570 - Avoid DocumentChannel for nsParser-created initial about:blank replacement. 3 years ago Henri Sivonen (:hsivonen) 48 bytes, text/x-phabricator-request		Details \| Review
Bug 1736570 - Avoid DocumentChannel for nsParser-created initial about:blank replacement (ESR backport). 3 years ago Henri Sivonen (:hsivonen) 48 bytes, text/x-phabricator-request	RyanVM : approval-mozilla-esr91+	Details \| Review

Ratio	Test	Platform	Options	Absolute values (old vs new)
5%	google-docs SpeedIndex	linux1804-64-shippable-qr	cold fission webrender	1,249.83 -> 1,186.69
4%	espn dcf	android-hw-p2-8-0-android-aarch64-shippable-qr	warm webrender	644.48 -> 618.88
4%	google-docs SpeedIndex	linux1804-64-shippable-qr	cold fission webrender	1,243.88 -> 1,195.92
3%	google-docs ContentfulSpeedIndex	linux1804-64-shippable-qr	cold fission webrender	1,768.32 -> 1,719.42
2%	espn dcf	android-hw-g5-7-0-arm7-shippable-qr	warm webrender	1,677.31 -> 1,643.75

Outlook OWA Automatic Replies not working - _event error or broken fields.

Client Information

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:93.0) Gecko/20100101 Firefox/93.0 CPU Class: undefined Platform: Win32 System Language: undefined User Language: de-DE CookieEnabled: true

Exception Details

Call Stack

Dump Event

Detailed Call Stack

Improvements:

ESR Uplift Approval Request

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:93.0) Gecko/20100101 Firefox/93.0
CPU Class: undefined
Platform: Win32
System Language: undefined
User Language: de-DE
CookieEnabled: true