Bug 1275384 - Dispatch mousedown, mouseup and click events manually on <select> for e10s instead of using DOMWindowUtils. r=Felipe, a=sylvestre
authorMike Conley <mconley@mozilla.com>
Wed, 25 May 2016 13:21:23 -0400
changeset 335290 5fe894994e955cf7f6d85337492beebe562ea6c5
parent 335289 46d72a56c57dafb4dc1061d4741a3e1181ac3d68
child 335291 1f9f6bdee31c14fd5a39485e8ae326de2928ef7d
push id1146
push userCallek@gmail.com
push dateMon, 25 Jul 2016 16:35:44 +0000
treeherdermozilla-release@a55778f9cd5a [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
reviewersFelipe, sylvestre
bugs1275384
milestone48.0
Bug 1275384 - Dispatch mousedown, mouseup and click events manually on <select> for e10s instead of using DOMWindowUtils. r=Felipe, a=sylvestre 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;