Closed
Bug 1280534
Opened 8 years ago
Closed 8 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)
Tracking
()
RESOLVED
FIXED
mozilla51
People
(Reporter: prittman, Assigned: nika)
References
Details
(Keywords: site-compat, Whiteboard: [platform-rel-Microsoft][platform-rel-Outlook])
Attachments
(1 file)
1.05 KB,
patch
|
nika
:
review+
ritu
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
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 2•8 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)
Updated•8 years ago
|
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.
Updated•8 years ago
|
platform-rel: --- → ?
Comment 4•8 years ago
|
||
Hello Maire, Can you please look into this or direct to the right person. Thanks!
Flags: needinfo?(mreavy)
Comment 5•8 years ago
|
||
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•8 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
I don't see an outlook icon in my system tray, per the instructions in the link.
Comment 8•8 years 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.
Comment 9•8 years ago
|
||
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?
Comment 11•8 years ago
|
||
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•8 years ago
|
||
I experienced the problem on Linux.
Comment 13•8 years 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.
Comment 14•8 years ago
|
||
(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•8 years ago
|
||
The login form should have a checkbox labeled "Use the light version of Outlook Web App".
Updated•8 years ago
|
platform-rel: ? → +
Comment 16•8 years ago
|
||
OK, I can reproduce this now
Comment 17•8 years ago
|
||
Boris, this is reproducible with owa.mit.edu, can you have a look? Anything jump out at you?
Flags: needinfo?(bzbarsky)
Comment 18•8 years 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•8 years 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.
Reporter | ||
Comment 21•8 years 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.
Updated•8 years ago
|
Flags: needinfo?(bzbarsky)
Assignee | ||
Comment 22•8 years 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•8 years 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.
Comment 24•8 years ago
|
||
sounds like you've got the info you need. Ping me if you need more
Flags: needinfo?(blassey.bugs)
Updated•8 years ago
|
Flags: needinfo?(stephen.moehle)
Reporter | ||
Comment 25•8 years 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•8 years ago
|
||
Oops. I forgot to ping you. We couldn't get access to a outlook web access account.
Flags: needinfo?(blassey.bugs)
Assignee | ||
Comment 28•8 years 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)
Comment 29•8 years ago
|
||
I sent Michael a "save page, complete" of an owa message display showing the problem.
Flags: needinfo?(blassey.bugs)
Assignee | ||
Comment 30•8 years 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.
Comment 31•8 years ago
|
||
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•8 years 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?
Comment 33•8 years ago
|
||
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•8 years 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)
Comment 35•8 years ago
|
||
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...
Updated•8 years ago
|
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
Comment 36•8 years ago
|
||
[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...
Status: UNCONFIRMED → NEW
status-firefox50:
--- → affected
status-firefox51:
--- → affected
tracking-firefox50:
--- → ?
tracking-firefox51:
--- → ?
Ever confirmed: true
Comment 37•8 years ago
|
||
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)
Comment 38•8 years ago
|
||
Well, we should anyhow backout bug 1242718 from FF50.
Assignee | ||
Comment 39•8 years ago
|
||
Assignee | ||
Comment 40•8 years 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•8 years ago
|
Assignee: nobody → michael
Comment 41•8 years 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•8 years 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?
Comment 43•8 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/21fb1f17d958
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla51
Hello Prittman, could you please verify this issue is fixed as expected on a latest Nightly build? Thanks!
Reporter | ||
Comment 46•8 years 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+
Comment 48•8 years ago
|
||
https://hg.mozilla.org/releases/mozilla-aurora/rev/6b222a7b59be
Flags: needinfo?(prittman)
Updated•8 years ago
|
Keywords: site-compat
You need to log in
before you can comment on or make changes to this bug.
Description
•