Closed Bug 1280534 Opened 3 years ago Closed 3 years ago

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

Categories

(Core :: DOM: Events, defect)

50 Branch
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla51
Tracking Status
platform-rel --- +
firefox50 + fixed
firefox51 + fixed

People

(Reporter: prittman, Assigned: Nika)

References

Details

(Keywords: site-compat, Whiteboard: [platform-rel-Microsoft][platform-rel-Outlook])

Attachments

(1 file)

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.
This has only been happening for the last week or so.
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]
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.
platform-rel: --- → ?
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)
(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
I don't see an outlook icon in my system tray, per the instructions in the link.
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)
I experienced the problem on Linux.
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)
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)
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)
(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)
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)
(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)
Flags: needinfo?(stephen.moehle)
This bug has now migrated to FDE. I am on the updated 50 (updated 27 Aug) and it is still here.
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)
(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)
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(!).
(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)
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
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.
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: nobody → michael
Depends on: 1298970
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
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
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla51
Tracking 51+ for this for the reasons in Comment 36.
Hello Prittman, could you please verify this issue is fixed as expected on a latest Nightly build? Thanks!
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+
You need to log in before you can comment on or make changes to this bug.