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

RESOLVED FIXED in Firefox 50

Status

()

Core
DOM: Events
RESOLVED FIXED
2 years ago
a year ago

People

(Reporter: prittman, Assigned: mystor)

Tracking

({site-compat})

50 Branch
mozilla51
site-compat
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(platform-rel +, firefox50+ fixed, firefox51+ fixed)

Details

(Whiteboard: [platform-rel-Microsoft][platform-rel-Outlook])

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
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.
(Reporter)

Comment 1

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

Comment 2

2 years ago
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!
Flags: needinfo?(prittman)
Whiteboard: [platform-rel-Microsoft][platform-rel-Outlook]
(Reporter)

Comment 3

2 years ago
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.

Updated

2 years ago
platform-rel: --- → ?

Comment 4

2 years ago
Hello Maire, Can you please look into this or direct to the right person. Thanks!
Flags: needinfo?(mreavy)
This is nowhere near my area of expertise.  My best guess is this is layout; so I'm moving my needinfo to Jet.
Flags: needinfo?(mreavy) → needinfo?(bugs)

Comment 6

2 years ago
(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
(Reporter)

Comment 7

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

Comment 8

a year ago
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.
Brad: Have we gotten hold of an Exchange server to test against? Ideally, one that matches comment 8. Thx!
Flags: needinfo?(bugs) → needinfo?(blassey.bugs)
(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?
I have access to version 14.3.123.0. On Nightly on OSX I can select the text. Is this problem windows specific?
Flags: needinfo?(blassey.bugs)

Comment 12

a year ago
I experienced the problem on Linux.

Comment 13

a year ago
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.
(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?
Flags: needinfo?(stephen.moehle)

Comment 15

a year ago
The login form should have a checkbox labeled "Use the light version of Outlook Web App".
platform-rel: ? → +
OK, I can reproduce this now
Boris, this is reproducible with owa.mit.edu, can you have a look? Anything jump out at you?
Flags: needinfo?(bzbarsky)

Comment 18

a year ago
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

a year ago
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.
Michael, regression range points to you
Flags: needinfo?(michael)
(Reporter)

Comment 21

a year ago
(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.
Flags: needinfo?(bzbarsky)
(Assignee)

Comment 22

a year ago
Do you have access to a running instance of Outlook Web Access I could use to figure out the source of this issue?
Flags: needinfo?(michael) → needinfo?(blassey.bugs)
(Reporter)

Comment 23

a year ago
(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.
sounds like you've got the info you need. Ping me if you need more
Flags: needinfo?(blassey.bugs)

Updated

a year ago
Flags: needinfo?(stephen.moehle)
(Reporter)

Comment 25

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

Comment 26

a year ago
Oops. I forgot to ping you. We couldn't get access to a outlook web access account.
Flags: needinfo?(blassey.bugs)
What do you need?
Flags: needinfo?(blassey.bugs)
(Assignee)

Comment 28

a year ago
(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.
Flags: needinfo?(blassey.bugs)
I sent Michael a "save page, complete" of an owa message display showing the problem.
Flags: needinfo?(blassey.bugs)
(Assignee)

Comment 30

a year ago
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.
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(!).
(Reporter)

Comment 32

a year ago
(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?
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...
Flags: needinfo?(bugs)
Flags: needinfo?(annevk)

Comment 34

a year ago
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.
Flags: needinfo?(annevk)
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...
Component: Untriaged → DOM: Events
Product: Firefox → Core
Summary: Outlook Web Access in Nightly will not let me select text in emails → Outlook Web Access in Nightly will not let me select text in emails because cancelBubble is not on Event
[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...
Blocks: 571294, 1242718
Status: UNCONFIRMED → NEW
status-firefox50: --- → affected
status-firefox51: --- → affected
tracking-firefox50: --- → ?
tracking-firefox51: --- → ?
Ever confirmed: true
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.
Flags: needinfo?(bugs)
Well, we should anyhow backout bug 1242718 from FF50.
(Assignee)

Comment 39

a year ago
Created attachment 8786105 [details] [diff] [review]
backout Bug 1242718 (Enable Select Events outside of Nightly) due to OWA breakage
(Assignee)

Comment 40

a year ago
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
Attachment #8786105 - Flags: review+
(Assignee)

Updated

a year ago
Assignee: nobody → michael
(Assignee)

Updated

a year ago
Depends on: 1298970

Comment 41

a year ago
Pushed by michael@thelayzells.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/21fb1f17d958
backout Bug 1242718 (Enable Select Events outside of Nightly) due to OWA breakage, r=smaug
(Assignee)

Comment 42

a year ago
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
Attachment #8786105 - Flags: approval-mozilla-aurora?
https://hg.mozilla.org/mozilla-central/rev/21fb1f17d958
Status: NEW → RESOLVED
Last Resolved: a year ago
status-firefox51: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla51
Tracking 51+ for this for the reasons in Comment 36.
tracking-firefox51: ? → +
Hello Prittman, could you please verify this issue is fixed as expected on a latest Nightly build? Thanks!
tracking-firefox50: ? → +
(Reporter)

Comment 46

a year ago
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 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.
Attachment #8786105 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
https://hg.mozilla.org/releases/mozilla-aurora/rev/6b222a7b59be
status-firefox50: affected → fixed
Flags: needinfo?(prittman)
Keywords: site-compat
You need to log in before you can comment on or make changes to this bug.