Bug 1275384 - Dispatch mousedown, mouseup and click events manually on <select> for e10s instead of using DOMWindowUtils. r=Felipe
authorMike Conley <mconley@mozilla.com>
Wed, 25 May 2016 13:21:23 -0400
changeset 340234 b53187f3dc44efa6562b0d0d88b91e118acaae53
parent 340231 0501a5c9908e7a6dadbb11155de1132e0a53ac3e
child 340235 20c1a4ec995f4177693cf0432263ed4bd4fbd222
push id1183
push userraliiev@mozilla.com
push dateMon, 05 Sep 2016 20:01:49 +0000
treeherdermozilla-release@3148731bed45 [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
reviewersFelipe
bugs1275384
milestone49.0a1
first release with
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
last release without
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
Bug 1275384 - Dispatch mousedown, mouseup and click events manually on <select> for e10s instead of using DOMWindowUtils. r=Felipe We were using nsIDOMWindowUtils to send mousedown and mouseup events to the <select> input after a selection was made in e10s mode, but doing so causes focus to be pulled back to the <select> if any input or change event handlers tried to shift focus. For example, the reviewer input on Bugzilla was having its focus stolen after setting the review flag to r?, which was how this bug was discovered. We're going for mostly-Blink parity here, where it seems (at least on Windows) a mouseup and click event are dispatched on <select> elements after the dropdown is closed (either by mouse or keyboard). We're adding a mousedown just before those, since that seems to make the most sense. MozReview-Commit-ID: HAThE6ClBWT
toolkit/modules/SelectContentHelper.jsm
--- a/toolkit/modules/SelectContentHelper.jsm
+++ b/toolkit/modules/SelectContentHelper.jsm
@@ -119,21 +119,30 @@ this.SelectContentHelper.prototype = {
           });
           this.element.dispatchEvent(inputEvent);
 
           let changeEvent = new win.Event("change", {
             bubbles: true,
           });
           this.element.dispatchEvent(changeEvent);
 
-          let dwu = win.QueryInterface(Ci.nsIInterfaceRequestor)
-                       .getInterface(Ci.nsIDOMWindowUtils);
-          let rect = this.element.getBoundingClientRect();
-          dwu.sendMouseEvent("mousedown", rect.left, rect.top, 0, 1, 0, true);
-          dwu.sendMouseEvent("mouseup", rect.left, rect.top, 0, 1, 0, true);
+          // Going for mostly-Blink parity here, which (at least on Windows)
+          // fires a mouseup and click event after each selection -
+          // even by keyboard. We're firing a mousedown too, since that
+          // seems to make more sense. Unfortunately, the spec on form
+          // control behaviours for these events is really not clear.
+          const MOUSE_EVENTS = ["mousedown", "mouseup", "click"];
+          for (let eventName of MOUSE_EVENTS) {
+            let mouseEvent = new win.MouseEvent(eventName, {
+              view: win,
+              bubbles: true,
+              cancelable: true,
+            });
+            this.element.dispatchEvent(mouseEvent);
+          }
         }
 
         this.uninit();
         break;
 
       case "Forms:MouseOver":
         DOMUtils.setContentState(this.element, kStateHover);
         break;