Mousemove doesn't dispatch after mousedown over an iframe




8 years ago
7 years ago


(Reporter: fake_healer, Unassigned)


({dom2, regression, testcase})

Windows 7
dom2, regression, testcase

Firefox Tracking Flags

(Not tracked)




(1 attachment)



8 years ago
User-Agent:       Mozilla/5.0 (Windows NT 6.1; rv:2.0b8) Gecko/20100101 Firefox/4.0b8
Build Identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0b8) Gecko/20100101 Firefox/4.0b8

The event mousemove is not dispatch when mousedown has been triggered over an iframe, and the mouse is still down.

This works in Firefox 3.6 and earlier.

In a drag and drop emulation, an "overlay" div (which covers the whole window) is used to trigger on "mousemove". But when the "dragstart" event (represented by mousedown) starts over an iframe, the overlay div doesn't receive any event.

Reproducible: Always

Steps to Reproduce:
1. Use this code:

    * {
      -moz-user-select: none;
      function showOverlay() {
        var overlay = document.getElementById("overlay"); = "block";
      function hideOverlay() {
        var overlay = document.getElementById("overlay"); = "none";
      function Test() {
        var oThis = this;
        oThis.startMoving = function(evt) {
          test_startMoving.apply(oThis, new Array(evt));
        oThis.Moving = function(evt) {
          test_Moving.apply(oThis, new Array(evt));
        oThis.stopMoving = function(evt) {
          test_stopMoving.apply(oThis, new Array(evt));
      function test_startMoving(evt) {
        var overlay = document.getElementById("overlay");
        overlay.addEventListener("mousemove", this.Moving, false);
        overlay.addEventListener("mouseup", this.stopMoving, false);
      function test_Moving(evt) {
        var MoveObject = document.getElementById("MoveObject"); = evt.clientX - 50; = evt.clientY - 50; = "block";
      function test_stopMoving(evt) {
        var overlay = document.getElementById("overlay");
        overlay.removeEventListener("mousemove", this.Moving, false);
        overlay.removeEventListener("mouseup", this.stopMoving, false);
    <div id="MoveObject" style="position:absolute;width:100px;height:100px;left:50%;top:50%;background-color:yellow;z-index:0;">
      <div>Moving Object</div>
    <div id="overlay" style="width:100%;height:100%;position:absolute;top:0px;left:0px;background-color:#ffcccc;opacity:0.5;display:none;z-index:10;"></div>
    <iframe  id="win" name="win" style="position:absolute;width:400px;height:400px;">
      // FF3.5 b4 works FF3.6 works, FF4b6 fail
      var content ="<div STYLE='position:absolute;top:10;left:10;height:380px;width:380px;background-color:#00ff00;opacity:0.5'>Iframe Click here to drag 'Moving Object'</div>";
      var win = window["win"];
      var test = new Test();
      var ifrm = document.getElementById('win');
      ifrm = (ifrm.contentWindow) ? ifrm.contentWindow : (ifrm.contentDocument.document) ? ifrm.contentDocument.document : ifrm.contentDocument;;
      win.document.body.addEventListener("mousedown", test.startMoving, false);

2. Mousedown on the green iframe and move the mouse around, without letting go of the button.
Actual Results:  
The yellow div doesn't move.

Expected Results:  
The yellow div should move with the mouse.

This works in Firefox 3.6 and earlier versions.

Comment 1

8 years ago
Created attachment 503435 [details]
Same testcase as in the link.


8 years ago
Keywords: dom2
Whiteboard: Mousemove doesn't dispatch after mousedown over an iframe
Repro'd with Mozilla/5.0 (Windows NT 5.1; rv:2.0b10pre) Gecko/20110113 Firefox/4.0b10pre ID:20110113030355.
Component: General → DOM
Keywords: regression, regressionwindow-wanted, testcase
Product: Firefox → Core
QA Contact: general → general
Summary: → Mousemove doesn't dispatch after mousedown over an iframe
Whiteboard: Mousemove doesn't dispatch after mousedown over an iframe
Version: unspecified → Trunk
Ever confirmed: true
Isn't this just because of mouse capture?
Last good nightly: 2010-10-28 First bad nightly: 2010-10-29

=> candidate: Bug 606192
Component: DOM → Event Handling
Keywords: regressionwindow-wanted
QA Contact: general → events
Bah, it is tricky to get mouse event handling to work the same way it worked 
before bug 130078, partly because it isn't standardized at all.

Comment 6

8 years ago
This bug turned out to be a blocker for us now that Firefox 4 has been released.

Any chance some poor soul would give it a try? :)

Comment 7

7 years ago
How about a workaround?

I have an odd one:
While holding down the mouse button, I then alt-tab to another app and then alt-tab back (remember to keep holding mouse button down throughout) then the mousemove events start firing okay.

Is there a way to force this? I can't ask users to alt-tab away and then back.

Another workaround is to remove "preventDefault()" which fixes mousemove, but the text selection is now messing up the look of the drag and drop. Is there a way to just turn off selection without using preventDefault?

It seems like preventDefault() became broken in FF4 build 7 ... and now through FF9.

Comment 8

7 years ago
I meant beta 7, not build 7.
preventDefault() is broken in more than just the specific case of this bug? If so please file a new bug for that.

Comment 10

7 years ago
This bug describes my problem very well. I am trying to figure out a workaround. 

Daniel wrote in his test code "FF3.5 b4 works FF3.6 works, FF4b6 fail," but maybe he had a typo because the problem first appears in FF4b7.

Since FF4b7, "preventDefault" appears to have this bad side-effect.

Comment 11

7 years ago
Hi, I need to retract my last comments on workarounds. Also, my comments about "preventDefault" should be ignored too. My issue seems to be different than Daniel's. But the same code changes to Firefox might have caused both our issues.

For my issue, the new methods in FF4 for setCapture caused my app to break because my custom methods setCapture methods were no longer called. The same thing happened to Jeff:
I have renamed my methods to something like setMyCapture and all seems to work fine now.

For Daniel, the same code to fix defect 503943 might cause his issue since that defect mentions beta 6 like Daniel wrote too.
Daniel, check out 603550 which is derived from that comment # 46 in 503943:
You need to log in before you can comment on or make changes to this bug.