New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 182 users

Comments by non-members will not trigger notification emails to users who starred this issue.

Issue metadata

Status: Fixed
Owner:
Closed: Oct 2014
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 0
Type: Bug



Sign in to add a comment

Outlook 2013 Calendar broken in Chrome 38

Reported by joppekr...@gmail.com, Sep 2 2014

Issue description

Chrome Version       : 39.0.2138.3 (Official Build 2b817dc47cd9) dev-m
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
  Firefox 31: OK
  IE 11: OK

What steps will reproduce the problem?
0. Have appointments
1. Open Outlook WebApp
2. Go to Calendar
3. No appointments visible 
4. Press "New Event" Button
5. Only gray page shows

What is the expected result?
- All appointments are shown in Calendar
- New Event page is shown when "New Event" Button is pressed

What happens instead?
Calendar is not interactive as it should be, Appointments are not shown (Empty Calendar.png), new event page does not display (New event.png).



Please provide any additional information below. Attach a screenshot if
possible.

 
New event.png
17.8 KB View Download
Empty Calendar.png
56.7 KB View Download
Showing comments 51 - 150 of 150 Older

Comment 51 by Deleted ...@, Oct 17 2014

Version 38.0.2125.104 m still having the same problem
Started chrome on Mac with --enable-show-modal-dialog: the problem is still existing and the calendar entries don't show.

Command:

open /Applications/Google\ Chrome.app --args --enable-show-modal-dialog
Cc: danno@chromium.org jochen@chromium.org
Owner: machenb...@chromium.org
bisect build points to https://chromium.googlesource.com/chromium/src/+/a0788089f54f8b4369982478c9241c9dc2374ca9 as the culprit.
Owner: atwilson@chromium.org
Actually, might be the previous webkit roll - still bisecting.
Same issue here on chrome 38.0.2125.101 m on Windows 7 Enterprise SP1 64bit

In IE and FireFox it works well.
Looks like my original comment (#53) was correct - it's the V8 roll. Jochen and I continue to bisect to find the commit.
Cc: rossberg@chromium.org
I bisected this to https://codereview.chromium.org/446023002

apparently enabling ES6 iterables broke OWA

Cc: -rossberg@chromium.org atwilson@chromium.org
Labels: -Pri-1 Pri-0
Owner: rossberg@chromium.org
Andreas, can you take a look at this? It's a Pri-0 issue because it breaks Outlook Web Access. Ping me and I can provide repro instructions (requires access to an Exchange instance).
25000 user University here with no control over browser-usage.  This and the showmodaldialog are big deals for us.
Cc: wi...@igalia.com rossberg@chromium.org
Owner: adamk@chromium.org
Andy, Adam, can you have a look? This seems urgent.
Not sure if this is related.

When using Outlook Web Access 2013 in Chrome 38, when replying to an email, if I do it all within the reading pane, the reply dialogue comes up fine.

But, when opening up the email in a separate window, and then going to reply, the dialogue that comes up is not autofilled.

I've confirmed that this works fine in Internet Explorer/Firefox/Safari.

Comment 64 by cwast...@gmail.com, Oct 17 2014

@12Knocks that's another modalDialog thread; that's an intentional elimination of an API that OWA 2010 uses but has been removed from Chrome. This is purely a regression from Chrome. 

Comment 65 by Deleted ...@, Oct 17 2014

Also wanted to mention etrade.com website seems also broken by whatever happened.  Cannot login just keeps saying need to login, The page looks bad, (Verified webpage is correct) however if you use FF or Safari no issues


Labels: Restrict-AddIssueComment-EditIssue
Restricting comments because we feel we know the cause and have a repro, so like to restrict bug traffic to developer comments.

Comment 67 by wingo@chromium.org, Oct 17 2014

The changes added in that CL that might be the cause of this breakage:

  * Addition of values, entries, and keys to Array.prototype, all in Array.prototype[Symbol.unscopables], not enumerable
  * Addition of @@iterator to Array.prototype and String.prototype

I suspect something is checking if there is a 'values', 'keys', or 'entries' property on an array.  Adam do you have time to dive in and see if you can get the OWA JS code?  I can pick up triage on Monday once we have the JS files that OWA uses.
Reverting the following revs works for me locally: 22980, 22992, 22994, 23001

here's a cl for all four of them: https://codereview.chromium.org/658423002

this unships unscopables and iterables
Cc: arv@chromium.org

Comment 70 by arv@chromium.org, Oct 17 2014

It looks like Microsoft fixed their site.

Comment 71 by arv@chromium.org, Oct 17 2014

Sorry, I was testing with Outlook.com... Ignore me.

Comment 72 by arv@chromium.org, Oct 17 2014

Cc: domenic@chromium.org
outlook 365 also works
Status: Assigned
Labels: Hotlist-ConOps
I was able to test this on my personal Outlook 365 for Small Businesses, hosted at https://outlook.com/owa/office365.com. I was not affected in either Chrome Stable 37 or Canary 40.

The calendar looked the same as the one in the OP, with the exception of saying "Office 365" instead of "Outlook Web App" in the upper-left.

I would guess this has been fixed by Microsoft... Although the fix may not have rolled out to older installations of the Outlook Web App that users have been deploying in their corporate environments.

Comment 76 by adamk@chromium.org, Oct 17 2014

@75, see title: the broken version is Outlook 2013.
Unable to reproduce this issue on Win7/64 bit using both 38.0.2125.104 [32 bit & 64 bit] chrome. Used MS OWA 2013.
409858 Win7 M38.PNG
243 KB View Download
To be clear, as far as I can tell this doesn't impact Office 365 or microsoftonline.com or any of their hosted products so you won't be able to reproduce it there. It impacts OWA on Exchange 2013. I've pinged adamk with repro steps, so please coordinate with him on repros.
pucchakayala: note that your screenshot is different from the one in comment #1 (and is different from the version of OWA that I was able to repro this on). Perhaps there are different versions of Exchange 2013, and it works on some of them but not others? See comment #16 for more info about versions.

Comment 80 by adamk@chromium.org, Oct 17 2014

I believe I've confirmed that this is due to adding a 'values' property to Array.prototype (patch https://codereview.chromium.org/647703003).

In microsoft.exchange.clients.owa2.client.core.framework.js (formatted for readability):

_a.$2p.$4lv = function(n) {
    return $4(n)
        ? []
        : "String" in n
            ? $.makeArray(n.String)
            : "values" in n
                ? $.makeArray(n.values)
                : $.makeArray(n)
}

Comment 81 by adamk@chromium.org, Oct 17 2014

https://codereview.chromium.org/647703003 is ready for review (it stops adding 'values' to Array.prototype and updates related tests).

Comment 82 by adamk@chromium.org, Oct 17 2014

Landed in v8 in https://code.google.com/p/v8/source/detail?r=24706 (also followup test-only patch https://code.google.com/p/v8/source/detail?r=24708). Next steps are to get it merged into v8 trunk and rolled into Chromium.
Labels: Hotlist-Enterprise

Comment 84 by danno@chromium.org, Oct 17 2014

Pushed to trunk in V8 version 3.30.13 (revision 24709). Chromium roll in progress here:

https://codereview.chromium.org/664783002/

Once it's in Chrome and has Canary coverage, we can merge it back to M38.
OWA sysadmins: Here's a workaround you can do until you can update to a fixed version of Chrome:

http://windowssystemspecialist.blogspot.com/2014/10/fixing-blank-calendar-with-chrome-38.html

Comment 86 by adamk@chromium.org, Oct 20 2014

This made it into the 2093 canary, so we have a couple days of coverage now. Need to merge into V8's M38 release branch.
Thanks Adam, Danno, Drew.

Is anyone on this bug thread facing a similar issue with Microsoft Dynamics CRM - lookup fields?
http://support2.microsoft.com/kb/3008160

It also started with 38 - trying to determine if this related or a completely different issue. If anyone has access to Dynamics CRM 2013 or 2011, please try with Chrome 38 and let us know the result.
Cc: vivianz@chromium.org

Comment 89 by adamk@chromium.org, Oct 20 2014

I should have said "2193", not "2093", btw.

Comment 90 by adamk@chromium.org, Oct 20 2014

@saswat, I have no access to that product. Seems like you should file a separate issue until there's reason to think it's related.

Comment 91 by adamk@chromium.org, Oct 20 2014

Labels: -Needs-Feedback -Cr-Blink-Rendering -Needs-Bisect -Needs-Reduction Cr-Blink-JavaScript Merge-Requested

Comment 92 by amin...@google.com, Oct 20 2014

Labels: merge-questions-applied

Please note that all merge requests must have been on or rolled into trunk
for at least 24 hours to be considered for merging (to ensure full bot
coverage and give an opportunity for any necessary reverts to occur).

To help facilitate this request, if you could please answer the following:
--------------------------------------------------------------------------
1) Has this change been on trunk for at least 24 hours?

2) Has this change shipped to at least one canary release (where applicable)?

3) Has anyone verified that these changes resolve the issue and cause no new
   crashes (via chromecrash/) or regressions?

4) Why is this necessary for this milestone?

Thanks!

(this message is auto-generated each time the merge-request label is
applied; if you have previously answered these questions kindly disregard)

Labels: -Merge-Requested Merge-Approved
Approved for 38.
Labels: M-39

Comment 95 by adamk@chromium.org, Oct 20 2014

Merge to the V8 branch is up for review at https://codereview.chromium.org/670533003/ (since this is my first time doing a V8 merge I don't feel comfortable TBRing it)
Project Member

Comment 96 by bugdroid1@chromium.org, Oct 20 2014

Labels: -Merge-Approved merge-merged-3.28
The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/529541ecb58fd0d6df4dfbe41d01bff9ae21ff06

commit 529541ecb58fd0d6df4dfbe41d01bff9ae21ff06
Author: adamk@chromium.org <adamk@chromium.org>
Date: Mon Oct 20 20:15:35 2014

Version 3.28.71.17 (merged r24706, r24708)

Don't expose Array.prototype.values as it breaks webcompat

Fix webkit getOwnPropertyNames test after r24706 removed Array.prototype.values

BUG= chromium:409858 
LOG=N
R=danno@chromium.org

Review URL: https://codereview.chromium.org/670533003

git-svn-id: https://v8.googlecode.com/svn/branches/3.28@24747 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

[modify] https://chromium.googlesource.com/v8/v8.git/+/529541ecb58fd0d6df4dfbe41d01bff9ae21ff06/src/array-iterator.js
[modify] https://chromium.googlesource.com/v8/v8.git/+/529541ecb58fd0d6df4dfbe41d01bff9ae21ff06/src/array.js
[modify] https://chromium.googlesource.com/v8/v8.git/+/529541ecb58fd0d6df4dfbe41d01bff9ae21ff06/src/version.cc
[modify] https://chromium.googlesource.com/v8/v8.git/+/529541ecb58fd0d6df4dfbe41d01bff9ae21ff06/test/mjsunit/es6/array-iterator.js
[modify] https://chromium.googlesource.com/v8/v8.git/+/529541ecb58fd0d6df4dfbe41d01bff9ae21ff06/test/mjsunit/es6/typed-array-iterator.js
[modify] https://chromium.googlesource.com/v8/v8.git/+/529541ecb58fd0d6df4dfbe41d01bff9ae21ff06/test/webkit/fast/js/Object-getOwnPropertyNames-expected.txt
[modify] https://chromium.googlesource.com/v8/v8.git/+/529541ecb58fd0d6df4dfbe41d01bff9ae21ff06/test/webkit/fast/js/Object-getOwnPropertyNames.js

Project Member

Comment 97 by bugdroid1@chromium.org, Oct 20 2014

Labels: merge-merged-3.29
The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/69b9761562d490efb776b957b1439ad81b5c313a

commit 69b9761562d490efb776b957b1439ad81b5c313a
Author: adamk@chromium.org <adamk@chromium.org>
Date: Mon Oct 20 21:00:30 2014

Version 3.29.88.10 (merged r24706, r24708)

Don't expose Array.prototype.values as it breaks webcompat

Fix webkit getOwnPropertyNames test after r24706 removed Array.prototype.values

BUG= chromium:409858 
LOG=N
R=danno@chromium.org

Review URL: https://codereview.chromium.org/667033002

git-svn-id: https://v8.googlecode.com/svn/branches/3.29@24748 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

[modify] https://chromium.googlesource.com/v8/v8.git/+/69b9761562d490efb776b957b1439ad81b5c313a/src/array-iterator.js
[modify] https://chromium.googlesource.com/v8/v8.git/+/69b9761562d490efb776b957b1439ad81b5c313a/src/array.js
[modify] https://chromium.googlesource.com/v8/v8.git/+/69b9761562d490efb776b957b1439ad81b5c313a/src/version.cc
[modify] https://chromium.googlesource.com/v8/v8.git/+/69b9761562d490efb776b957b1439ad81b5c313a/test/mjsunit/es6/arguments-iterator.js
[modify] https://chromium.googlesource.com/v8/v8.git/+/69b9761562d490efb776b957b1439ad81b5c313a/test/mjsunit/es6/array-iterator.js
[modify] https://chromium.googlesource.com/v8/v8.git/+/69b9761562d490efb776b957b1439ad81b5c313a/test/mjsunit/es6/typed-array-iterator.js
[modify] https://chromium.googlesource.com/v8/v8.git/+/69b9761562d490efb776b957b1439ad81b5c313a/test/webkit/fast/js/Object-getOwnPropertyNames-expected.txt
[modify] https://chromium.googlesource.com/v8/v8.git/+/69b9761562d490efb776b957b1439ad81b5c313a/test/webkit/fast/js/Object-getOwnPropertyNames.js

Status: Fixed
Looks like we're set here, marking as Fixed.

Comment 99 by adamk@chromium.org, Oct 20 2014

Labels: -Restrict-AddIssueComment-EditIssue
Commenting on this issue is now reopened - the fix is in on the Canary channel, so if any users are still seeing this in the field with the latest canary build, please let us know.
Tested the canary build: Fix solves the issue for us. We are looking forward to the stable release.
Thanks a lot!
I also tested the Canary Build and it working just fine. Is there a ETA on the next stable release to fix this issue?
Outlook Webapp Calendar works as intended again for me. Many thanks!
What is the Canary Channel or the Canary Build?
I'm an end user, not a sys admin, and would love to have my calendars back.
Thanks
Do a Google search for "Chrome Canary" and it will lead you to a download site for your platform. I will warn everyone that the Canary build gets minimal manual testing - it is pretty much a daily build straight from the latest source code, including any bugs. So it's useful to confirm that this fixes your problem, but I would not recommend using it for your general browser (at least, not for any significant length of time).

Comment 106 by Deleted ...@, Oct 23 2014

Just like to add that my OWA works in Canary, but is broke in the current release version (all pages except initial login page shows as blank pages).

Comment 107 by dpar...@gmail.com, Oct 23 2014

I can confirm it's working in both Chrome beta 39.0.2171.36 and in Canary 40.0.2197.2. Thanks for the quick turn around. Though I won't be able to deploy either of these versions to our enterprise users, I know the fix is coming.

Comment 108 by dpar...@gmail.com, Oct 23 2014

I can confirm it's working in both Chrome beta 39.0.2171.36 and in
Canary 40.0.2197.2.
Thanks for the quick turn around. Though I won't be able to deploy either
of these versions to our enterprise users, I know the fix is coming.
Working here too, at least with Canary 40.0.2198.0 64-bit on Windows 7. Thanks so much for the fast handling of this! :D Will this fix make it into a v38 patch, or are we stuck waiting until v39?
Thanks for testing guys & confirming to us that the fix is working. Our aim is to bring it to 38 Stable by mid-next week.
Fantastic! Thanks for being so on top of this.
Great! Thank you very much for taking care of this issue. Much Appreciated! 
Cc: royans@chromium.org saswat@chromium.org
 Issue 422350  has been merged into this issue.
You guys rock!! I just now had a user report that the calendar was not working for him as of this morning and i was able to view it, compared versions and Im running
37.0.2062.124m, he is using 38.0.2125.104. Investigated and saw this article. 

Is there an ETA on when the next version release will be out that resolves this?

Thank you all 
 Issue 425605  has been merged into this issue.
 Issue 411142  has been merged into this issue.
 Issue 421844  has been merged into this issue.
Please see comment #110 for our estimate for releasing this fix to the stable channel.
Version 38.0.2125.111 m is live and solves the issue. tnx!
Version 38.0.2125.111m has resolved the this issue. Thank you Very Much for all the help! Much Appreciated!

Comment 121 Deleted

This still seems to be an issue on the Chrome mobile app.  I see this on Android 4.4.4, Chrome 38.0.2125.114.

I can confirm that this has been fixed in desktop version 38.0.2125.111 m.
Cc: kerz@chromium.org
kerz: did we re-roll Android M38 with this V8 fix yet?
Confirmed as well! Running on desktop Version 38.0.2125.111 m

Comment 125 by k...@google.com, Nov 3 2014

This will have to wait for 39 on Android.
@saswat@chromium.org - yes Addition of Array.prototype.values is the cause of the CRM 2013 lookup issue
I can confirm that this is now corrected with version 39 on Android.  Although on my device running 4.4.4, chrome now has other issues, but at least its running OWA correctly now.

Comment 128 Deleted

Comment 129 Deleted

Comment 130 Deleted

jean-sebastien.st-amour@sdpinternational.ca: Note that this bug is closed and verified. You should open a new bug with all relevant information and repro steps to increase the chance that your issue attracts attention.
Cc: pucchakayala@chromium.org
It appears this bug has re-appeared.  Comments in  issue 421440  (dupped to here) show other users having this issue again.
This will be fixed once Chrome 52 is released. In the meantime, you can use Chrome 52 Beta to work around the problem.
Adam, do you have a link to the bug covering this new regression?
This issue exists for me, Chrome Version 66.0.3359.139 (Official Build) (64-bit). I have AdBlocker Plus installed, but even if I disable the issue still persists.
This issue stops me from using Chrome as this problem reappeared since the last update. Unable to create new appointments and see the current appointments. Version 66.0.3359.181
Recent reporters of this issue, are you still using owa 2013 or something newer?

If something changed between 65 and 66 and you feel comfortable giving it a shot, you may be able to narrow down which change affected you by running Chrome bisect:

https://github.com/jay0lee/chrome-bisect

If you are able to do so, please attach logs here.
Owner: gsat...@chromium.org
comment#138, Can you disable the 'Array.prototype.values ES6 method' flag by going to chrome://flags/#enable-array-prototype-values and clicking 'Disabled'? Does that fix the issue?
comment#140 - Following that instruction and disabling the 'Array.prototype.values ES6 method' flag does indeed fix the issue for me. Are there any known consequences/issues that may occur from disabling this flag?

Comment 142 Deleted

Hello,

we are currently busy migrating our 6000 users mailbox from an exchange 20007 to exchange 2013, and our migrated users are facing the same problem in their webmail, their calendar remain empty, and they are unable to create a new appointment.

This problem appears some weeks ago, related - I suppose -  to a new release of Chrome, because our internal users with an oudated version of chrome don't have the problem (v63)

As said by the people above me, disabling the property "chrome://flags/#enable-array-prototype-values" seems to solve the problem, but this is kinda awful to explain by our helpdesk to external people consulting their agenda with their own pc.

Thanks for confirming that disabling the 'Array.prototype.values ES6 method' flag does fix the problem.

I'm very sympathetic to the problem here but this isn't a Chrome bug. Chrome is trying to adhere more closely to the ECMAScript specification by shipping Array.prototype.values. 

All the other major browsers (Firefox, Safari, Edge) do ship Array.prototype.values, effectively meaning that Exchange 2013 does not work on any of the major browsers.

This needs to be fixed in Exchange 2013. I've reached out to them to see if they can work on a fix. I would encourage you to reach out to them as well.

The 'Array.prototype.values ES6 method' flag is only a stop gap to correctly debug and diagnose the breakage, so I would expect this flag to go away in a future Chrome release. I had initially planned on removing this flag in Chrome 68, but will keep this longer to help with the transition.

comment#141 -- I would expect you to run into other website breakages in the future (once websites start using Array.prototype.values) if this flag is disabled.

comment#143 -- Can you give me more context about your set up? It seems that your internal users are facing issues from your hosted migration to Exchange 2013, but why does this affect external people?
I've just heard back from Microsoft that they no longer plan on updating this website -- this website will continue to be broken on all major browsers. 

I'd encourage users to migrate to an app that's maintained (I understand this isn't always possible, but we need you to be aware that there's a cost associated with using an un maintained app).

This means there's really no transition plan for removing the 'Array.prototype.values ES6' flag that doesn't involve any breakage. I plan on removing this flag in Chrome 68 as per the original plan.
Cc: -wi...@igalia.com winthrop@chromium.org
+ winthrop

gsathya@ please do not re-enable without at least allowing the enterprise team to communicate this change out to customers, we'd need to wait until at least 69 or 70 for that.

Winthrop, can we add this to the Enterprise release notes as an upcoming deprecation that may impact some Enterprise customers?
Cc: wi...@igalia.com
re-adding accidentally removed CC
btw, seems like the bug tracking the actual Chrome change is  crbug.com/845955  is that correct gsathya@?
This is already re-enabled as of Chrome 66.

There was a flag to disable this (through about://flags), but this flag has been removed in Chrome 68. Are you asking to wait until one more release to drop this flag? We've already branched for Chrome 68, so I'd rather not backmerge unless absolutely required. Can we add the release notes to Chrome 68?

re comment#148 -- That's about a different site but it's facing the same breakage due to the same reason. So if you could add that warning about that site (CRM 2011) to the release notes, that would be great too.
Actually, scratch that, I misunderstood that this has been in place for some time since 66. I think current plan is acceptable.

If any customers are still seeing this issue, please try installing the most recent Microsoft Exchange 2013 Cumulative Update. I was unable to reproduce the issue on an OWA 2013 with a more recent CU. For Cumulative Updates, see:

https://technet.microsoft.com/en-us/library/hh135098(v=exchg.150).aspx#Exchange%20Server%202013
Showing comments 51 - 150 of 150 Older

Sign in to add a comment