Open Bug 1259924 Opened 4 years ago Updated 18 days ago

[quirks mode] mousemove fails because <body> element height doesn't fill the viewport


(Core :: Layout, defect, P3)

45 Branch



Webcompat Priority ?


(Reporter: danielh, Unassigned, NeedInfo)



(Keywords: parity-chrome, parity-edge, Whiteboard: btpp-followup-2016-04-26)


(2 files, 1 obsolete file)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20160315153207

Steps to reproduce:

Wrote javascript/jquery code to move a container; using jquery's mousedown, mousemove, and mouseup.

See attached html file  for a complete demo.

Actual results:

If you move the mouse too quickly, problems occur.
This includes:
  1) container will stop moving. Sometimes moving mouse back over small element will re enable container movement
  2) when you undepress the mouse button, sometimes the container will move as you
   move the mouse. This can be hard to stop!

It seems that the mouseup event is NOT detected when the mouse gets moved too quickly.

Expected results:

Goal is to mousedown on a small element (say, a <button>), move mouse (with mouse depressed).  Parent container will move.  When you release mousebutton, movement should stop.

That is: movement of container should stop once mouse button is released.

Note: by pure chance, I discovered that if you have a <textarea> in the document, this problem goes away. It seems the textarea has to be at least 10 rows and 10 columns, and can not have a display:none style. However, it can have a visibilty:hidden style!

Note 2: this problem does NOT occur under Chrome or IE. So it isn't a purely jquery issue.
OS: Unspecified → Windows 7
Hardware: Unspecified → x86
Did you test your testcase after attaching to the bug report? I tested it and I don't see the container moving... Could you check, please.
Flags: needinfo?(danielh)
Just tried it and it worked.

I suspect the problem is you are running it directly, and I put a <script> to jquery that is local.
So -- 
replace the <script type="text/javascript" src="jquery-1.11.3.min.js"></script>

<script type="text/javascript" src=""></script>

I will upload an updated demo in the next comment

Or: just use this..
Flags: needinfo?(danielh)
<!-- demo mousemove problem.  Clicking on element and moving mouse should move parent container
    However, if you move the mouse too quickly, the parent container will stop moving.
    Or, the parent container will continue to move even after mouse button is released.
    It seems a mouseup is not detected.
    Note: adding a <textarea> seems to cure the problem

<head><title>Demo of jquery mousemove and firefox 45.0.1 problem </title>
<META  charset="utf-8">
<script type="text/javascript" src=""></script>

<style type="text/css">
.moveC {
   border:2px solid gold;

<script type="text/javascript">

function init1() {

//========  initialze the movement
function moveStart(evt){
  var q1,q1p;
  q1p.mouseup(function(){'mousemove')});  // this seems to be undetected when mouse is moved too quicly

function movePos(evt) {
  var atx,aty,q1,wasx,wasy,adat,ds,dy,goo,gooy,goox;
  atx=evt.pageX; aty=evt.pageY ;            // current mouse location

  q1=$('#move0');'atx');'aty');       // prior mouse location
  if (wasx<0) {{'atx':atx,'aty':aty});           // initialize
     return 1;

  dx=wasx-atx ; dy=wasy-aty ;                   // compute delta move
  if (Math.abs(dx)<2 && Math.abs(dy)<2) return 1 ;   // small moves: ignore

  goo=q1.offset();                       // upper left ; goox=goo.left;

  goox=goox-dx ; gooy=gooy-dy ;          // move upper left
  q1.offset({'left':goox,'top':gooy});{'atx':atx,'aty':aty});           // save prior mouse location

  return 1 ;

<body onLoad="init1()">

<div  id="move0" class="moveC"   title="moveable container">
     <button   id="mover" title="mousedown and move wil move parent container">O</button>
     Move me.


<!-- uncomment this to "cure" problem
  <textarea style="visibility:hidden" readonly  rows="10" cols="10" ></textarea>

Attached file show1.htm
Attachment #8735116 - Attachment is obsolete: true
Component: General → DOM: Events
Olli, what do you think is the issue here?
Flags: needinfo?(bugs)
Whiteboard: btpp-followup-2016-04-26
So the issue is that mousemove listener is added to the parent element of the box, which happens to be <body>, and in Gecko that element seems to have size (width=100%, height=0), so if mouse isn't over the descendants of <body>, it ends up being on top of viewport, not <body>, and so <body> never gets the events.

In Chrome and Edge the size of <body> is (100%, 100%) or some such.
I don't know why we behave differently here.
Component: DOM: Events → Layout
Flags: needinfo?(bugs) → needinfo?(dbaron)
Every time it comes up in the CSS working group, people say they don't want to add exceptions for body.  But so far other browsers have failed to remove theirs...
Flags: needinfo?(dbaron)
So is there anything we could do here? Or could you bring this up with the WG again?
Flags: needinfo?(dbaron)
Summary: mousemove fails when moving mouse quickly -- but not always → [quirks mode] mousemove fails because <body> element doesn't fill the viewport
Given that Chrome's behavior is quirks mode only, we should probably just emulate it.

needinfo? to zcorpan to spec the body height behavior in
Flags: needinfo?(dbaron) → needinfo?(zcorpan)
Summary: [quirks mode] mousemove fails because <body> element doesn't fill the viewport → [quirks mode] mousemove fails because <body> element height doesn't fill the viewport

Feedback welcome. Some more work is necessary for the "percentage height calculation quirk" and update tests...
Flags: needinfo?(zcorpan)
It seems that this fell off the radar...?

This just bit us again today on in issue #9045, so it's definitely still affecting sites.
Flags: webcompat?
Flags: needinfo?(dbaron)
In quirks mode,
Chrome, Edge:  green body height is 100% of viwport
Firefox:       blue  body height is 0

See bug 1547409. Moving webcompat whiteboard tags to project flags.

Webcompat Priority: --- → ?
Duplicate of this bug: 1559968

The Chrome and WebKit behavior is quite subtle last I looked at it, fwiw.

Ever confirmed: true
Priority: -- → P3
See Also: → 1566699
Duplicate of this bug: 1565826
OS: Windows 7 → All
Hardware: x86 → All
Duplicate of this bug: 1335860
You need to log in before you can comment on or make changes to this bug.