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

--HG--
extra : rebase_source : 33dea1361ecd114b563c2b972bb6d3811e9d779c
This commit is contained in:
Mike Conley 2016-05-25 13:21:23 -04:00
parent d685437e7b
commit 95cc0dafab

View File

@ -124,11 +124,20 @@ this.SelectContentHelper.prototype = {
}); });
this.element.dispatchEvent(changeEvent); this.element.dispatchEvent(changeEvent);
let dwu = win.QueryInterface(Ci.nsIInterfaceRequestor) // Going for mostly-Blink parity here, which (at least on Windows)
.getInterface(Ci.nsIDOMWindowUtils); // fires a mouseup and click event after each selection -
let rect = this.element.getBoundingClientRect(); // even by keyboard. We're firing a mousedown too, since that
dwu.sendMouseEvent("mousedown", rect.left, rect.top, 0, 1, 0, true); // seems to make more sense. Unfortunately, the spec on form
dwu.sendMouseEvent("mouseup", rect.left, rect.top, 0, 1, 0, true); // 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(); this.uninit();