1280534 - Outlook Web Access in Nightly will not let me select text in emails because cancelBubble is not on Event

Status: RESOLVED FIXED

(Core :: DOM: Events, defect)

Description

[prittman]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20160616030228

Steps to reproduce:

(1) Log in to an Outlook Web Access (this is NOT MS Office Outlook, or outlook.com email) account. 

(2) Click on an email to view the body of the email. 

(3) Click to select text in any email.


Actual results:

Absolutely nothing happens.


Expected results:

I should see any selected text in the body of the email, become blocked out.

Comment 1

[prittman]

This has only been happening for the last week or so.

Comment 2

[Kanchan Kumari QA]

Hello Reporter, I tried duplicating this issue with Outlook Web Access account on

Version 	50.0a1
Build ID 	20160620030215
User Agent 	Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:50.0) Gecko/20100101 Firefox/50.0

I didn,t encounter any such issue. Does the problem still happen if you start Firefox in Safe Mode? (Safe Mode disables extensions and themes, hardware acceleration and some JavaScript stuff in order to exclude some possible reasons for problems. It does not disable plugins which are add-ons.) See http://support.mozilla.com/en-US/kb/Safe+Mode 

And does this also happen with a new and empty profile? See http://support.mozilla.com/en-US/kb/Basic%20Troubleshooting#w_8-make-a-new-profile and http://support.mozilla.org/kb/Managing%20profiles

Please retest with fresh profile and safe mode and let us know your finding. Thanks!

Comment 3

[prittman]

I just tried this with two different OWA accounts. I tried this with my old profile, in Safe Mode. I then created a new profile and tried it on Nightly then. I still got the same issue. 

I made sure NIghtly was updated to the latest version, first.

Comment 4

[Kanchan Kumari QA]

Hello Maire, Can you please look into this or direct to the right person. Thanks!

Comment 5

[Maire Reavy [:mreavy]]

This is nowhere near my area of expertise.  My best guess is this is layout; so I'm moving my needinfo to Jet.

Comment 6

[Jet Villegas (inactive)]

(In reply to prittman from comment #1)
> This has only been happening for the last week or so.

Please also indicate which version of the Microsoft Exchange Server you're connecting to.

https://support.office.com/en-us/article/Determine-the-version-of-Microsoft-Exchange-Server-my-account-connects-to-CAC9769B-39E7-4A74-8A0D-994BCA37AA7A

Comment 7

[prittman]

I don't see an outlook icon in my system tray, per the instructions in the link.

Comment 8

[Stephen Moehle]

I am experiencing the same problem. In my case, the Exchange Server is version 14.3.294 (Exchange Server 2010). It works fine with Firefox 47.

Comment 9

[Jet Villegas (inactive)]

Brad: Have we gotten hold of an Exchange server to test against? Ideally, one that matches comment 8. Thx!

Comment 10

[Desigan Chinniah [:cyberdees] [:dees] [London - GMT]]

(In reply to Jet Villegas (:jet) from comment #9)
> Brad: Have we gotten hold of an Exchange server to test against? Ideally,
> one that matches comment 8. Thx!

This request is with the Outlook team since we met with them in Redmond a few weeks back. They have an action to attempt a setup a few Azure VM based Exchange instances of the more popular deployments - but have not confirmed that this is even possible, yet. There was an update last week that it's still on their to-do queue for investigation.

Brad - we may need to revert to your suggestion of asking an old colleague who was an Exchange master?

Comment 11

[Brad Lassey [:blassey] (use needinfo?)]

I have access to version 14.3.123.0. On Nightly on OSX I can select the text. Is this problem windows specific?

Comment 12

[Stephen Moehle]

I experienced the problem on Linux.

Comment 13

[Stephen Moehle]

I tried again with the latest Nightly for Linux, and I still cannot select text. One thing to note is that the "light" version of Outlook Web App works but the standard (heavy?) version does not.

Comment 14

[Brad Lassey [:blassey] (use needinfo?)]

(In reply to Stephen Moehle from comment #13)
> I tried again with the latest Nightly for Linux, and I still cannot select
> text. One thing to note is that the "light" version of Outlook Web App works
> but the standard (heavy?) version does not.

how do you get the light versus heavy version?

Comment 15

[Stephen Moehle]

The login form should have a checkbox labeled "Use the light version of Outlook Web App".

Comment 16

[Brad Lassey [:blassey] (use needinfo?)]

OK, I can reproduce this now

Comment 17

[Brad Lassey [:blassey] (use needinfo?)]

Boris, this is reproducible with owa.mit.edu, can you have a look? Anything jump out at you?

Comment 18

[Stephen Moehle]

Mozregression leads me all the way back to September:

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=cd8b8017370cf14c472c107d256bb98ce7a19270&tochange=8853d35b1154f25259240308b83ae8d05359ab98

Bug 571294 and Bug 1196479, both of which have to do with selection.

Comment 19

[Stephen Moehle]

Bug 571294 added a new pref, dom.select_events.enabled, for the selection events, and added the following to all.js:

// Whether or not selection events are enabled
#ifdef NIGHTLY_BUILD
pref("dom.select_events.enabled", true);
#else
pref("dom.select_events.enabled", false);
#endif

If I set dom.select_events.enabled to false, selecting text works again in Outlook Web App.

Comment 20

[Brad Lassey [:blassey] (use needinfo?)]

Michael, regression range points to you

Comment 21

[prittman]

(In reply to Stephen Moehle from comment #19)
> Bug 571294 added a new pref, dom.select_events.enabled, for the selection
> events, and added the following to all.js:
> 
> // Whether or not selection events are enabled
> #ifdef NIGHTLY_BUILD
> pref("dom.select_events.enabled", true);
> #else
> pref("dom.select_events.enabled", false);
> #endif
> 
> If I set dom.select_events.enabled to false, selecting text works again in
> Outlook Web App.


Yes, I can confirm that when dom.select_events.enabled is set to false, selecting text works again in OWA.

Without this preference, however, even in the latest Nightly (8 Aug 2016) it still doesn't work.

Comment 22

[Nika Layzell [:nika] (ni? for response)]

Do you have access to a running instance of Outlook Web Access I could use to figure out the source of this issue?

Comment 23

[prittman]

(In reply to Michael Layzell [:mystor] from comment #22)
> Do you have access to a running instance of Outlook Web Access I could use
> to figure out the source of this issue?

Michael, I shot you an email about this. Please let me know if you need my assistance.

Comment 24

[Brad Lassey [:blassey] (use needinfo?)]

sounds like you've got the info you need. Ping me if you need more

Comment 25

[prittman]

This bug has now migrated to FDE. I am on the updated 50 (updated 27 Aug) and it is still here.

Comment 26

[Nika Layzell [:nika] (ni? for response)]

Oops. I forgot to ping you. We couldn't get access to a outlook web access account.

Comment 27

[Brad Lassey [:blassey] (use needinfo?)]

What do you need?

Comment 28

[Nika Layzell [:nika] (ni? for response)]

(In reply to Brad Lassey [:blassey] (use needinfo?) from comment #27)
> What do you need?

I was hoping to be able to reproduce the bug locally so that I could figure out where the problem is coming from and fix it. To do that I would either need access to an outlook web access account, or a minimal reproduction html document which exhibits the same behavior.

Comment 29

[Boris Zbarsky [:bzbarsky]]

I sent Michael a "save page, complete" of an owa message display showing the problem.

Comment 30

[Nika Layzell [:nika] (ni? for response)]

Alrighty. I did some investigation and as far as I can tell, this isn't our fault. 

The reason why chrome doesn't act the same way is because in Owa$Pages$NavigationPage$initialize(), the $("divMainView").forEachChild() function calls some code which raises an exception which causes the rest of the function to never be evaluated, including the e.attachEvent("selectstart",onSLSUnav) call. If I catch that exception, and ignore it, chrome acts the same way as firefox, not allowing selection of the text.

It seems like the problem is not on our end, because the website is explicitly adding a "selectstart" method which cancels itself to the root of the document, and the problem just doesn't reproduce on other browsers. We should ask the outlook team to look into it and fix it.

Comment 31

[Boris Zbarsky [:bzbarsky]]

So "dom.select_events.enabled" just makes us actually fire the selectstart event, which is why this problem doesn't show up without that pref?

I do see an exception with the thing I sent you in Chrome, but it's a security exception that's specific to their file:// same-origin policy.  If I load the same pages via http:// in Chrome, I don't get a security exception there, and the text is not selectable in Chrome either.  However, on the original OWA site the text _is_ selectable in Chrome.

I just checked in Chrome on the original site, and I definitely reach the "e.attachEvent("selectstart",onSLSUnav);" line.  But I don't see that listener getting called when I try selecting in the message pane in Chrome.  Again, on the OWA site; I do see it in my saved page version....

Oh, and I'm only seeing any of this stuff if look at a mail that's not in the inbox but is in some other folder (which ends up using the three-pane view with mail on the far right).  For mails in inbox OWA puts the mail body under the folder display and selection works fine in Firefox(!).

Comment 32

[prittman]

(In reply to Boris Zbarsky [:bz] from comment #31)
> So "dom.select_events.enabled" just makes us actually fire the selectstart
> event, which is why this problem doesn't show up without that pref?
> 
> I do see an exception with the thing I sent you in Chrome, but it's a
> security exception that's specific to their file:// same-origin policy.  If
> I load the same pages via http:// in Chrome, I don't get a security
> exception there, and the text is not selectable in Chrome either.  However,
> on the original OWA site the text _is_ selectable in Chrome.
> 
> I just checked in Chrome on the original site, and I definitely reach the
> "e.attachEvent("selectstart",onSLSUnav);" line.  But I don't see that
> listener getting called when I try selecting in the message pane in Chrome. 
> Again, on the OWA site; I do see it in my saved page version....
> 
> Oh, and I'm only seeing any of this stuff if look at a mail that's not in
> the inbox but is in some other folder (which ends up using the three-pane
> view with mail on the far right).  For mails in inbox OWA puts the mail body
> under the folder display and selection works fine in Firefox(!).

I was seeing it in emails in the inbox itself, from two different OWA accounts on FF nightly and now FDE--I was not able to select text.

As far as the dom.select_events.enabled pref, if I toggle it (in FF beta, it is default false; with FDE, the default is true), is there anything that might go wrong---with this or any other site? Or should I not mess with that pref?

Comment 33

[Boris Zbarsky [:bzbarsky]]

Gah.  Bugzilla just lost a long comment I was typing...  But short version:

In Chrome, on the original OWA site, I see "selectstart" listeners fire on two divs, and _not_ on the document.  In Firefox I see the listener fire only on the document, afaict.

It probably matters, in Chrome, that one of those two divs does this:

  event.cancelBubble = true;

somewhat indirectly via Owa.Dom.Event.prototype.cancelBubble.  In Chrome that prevents propagation to the document but in Firefox it does not.  Simple testcase:

  <div>
    Try selecting my text and watch the console.
  </div>
  <script>
    document.addEventListener("selectstart", function(e) {
      console.log("bubbled");
      e.preventDefault();
    });
    document.querySelector("div").addEventListener("selectstart", function(e) {
      console.log("canceled");
      e.cancelBubble = true;
    });
  </script>

in Firefox, "selectstart" events are instances of Event, not UIEvent.  The cancelBubble attribute lives on UIEvent in Gecko.  In Chrome, "selectstart" events are instances of Event, but "cancelBubble" also lives on Event.

So the first question is whether "cancelBubble" should move to Event.  That may not be enough to make this work, given that it still doesn't work in Chrome on the saved version, but it's an obvious point of incompatibility between browsers here...

Comment 34

[Anne (:annevk)]

We want to move it to Event: https://github.com/whatwg/dom/issues/211. I'm still trying to figure out if Chrome can first simplify the underlying semantics of that IDL attribute as their current implementation requires new primitives.

Comment 35

[Boris Zbarsky [:bzbarsky]]

OK, I just tried locally moving cancelBubble to Event, and that fixes the selection problem with OWA.

I also checked, and http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4423 shows that "cancelBubble" lives on Event in Safari, Chrome, and Edge.  Looks like there's been a DOM spec issue open for a while now at https://github.com/whatwg/dom/issues/211 too...

Comment 36

[Boris Zbarsky [:bzbarsky]]

[Tracking Requested - why for this release]: Breaks OWA

OK, in practice this looks like a regression from bug 1242718.  So we should either back that out on 50 or uplift the fix for this bug to 50...

Comment 37

[Olli Pettay [:smaug][[e-mail]]]

I think what mystor proposed on IRC to disable selectstart on 50 and move cancelBubble to Event sounds good, assuming moving cancelBubble fixes this issue.

Comment 38

[Olli Pettay [:smaug][[e-mail]]]

Well, we should anyhow backout bug 1242718 from FF50.

Comment 39

[Nika Layzell [:nika] (ni? for response)]

Attachment: backout Bug 1242718 (Enable Select Events outside of Nightly) due to OWA breakage

Comment 40

[Nika Layzell [:nika] (ni? for response)]

Comment on attachment 8786105 [details] [diff] [review]
backout Bug 1242718 (Enable Select Events outside of Nightly) due to OWA breakage

smaug r+-ed on IRC

Comment 41

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/21fb1f17d958
backout Bug 1242718 (Enable Select Events outside of Nightly) due to OWA breakage, r=smaug

Comment 42

[Nika Layzell [:nika] (ni? for response)]

Comment on attachment 8786105 [details] [diff] [review]
backout Bug 1242718 (Enable Select Events outside of Nightly) due to OWA breakage

Approval Request Comment
[Feature/regressing bug #]:1242718
[User impact if declined]:A version of select events which breaks OWA due to the lack of cancelBubble on event is shipped to beta/release populations. Potentially the cancelBubble fix could be uplifted instead.
[Describe test coverage new/current, TreeHerder]: N/A
[Risks and why]: All this does is disable a feature in aurora which was previously enabled, to avoid website breakage until a better fix can be developed. This feature was being enabled outside of nightly for the first time in FF 50. If a website was expecting FF50 to have select events and uses UA checking to discover this, it may break the website, but this is unlikely.
[String/UUID change made/needed]:None

Comment 43

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/21fb1f17d958

Comment 44

[Marcia Knous [:marcia]]

Tracking 51+ for this for the reasons in Comment 36.

Comment 45

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Hello Prittman, could you please verify this issue is fixed as expected on a latest Nightly build? Thanks!

Comment 46

[prittman]

Works for me! 
Thank you all for taking care of this. It works on the latest, updated Nightly, on both of my OWA accounts.

Comment 47

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8786105 [details] [diff] [review]
backout Bug 1242718 (Enable Select Events outside of Nightly) due to OWA breakage

Disabling a feature in Aurora50, makes sense.

Comment 48

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/6b222a7b59be