Open Bug 1259924 Opened 8 years ago Updated 10 days ago

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

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Version:
45 Branch
Type:
defect

Tracking

()

Project Flags:
Webcompat Priority P3

People

(Reporter: danielh, Unassigned)

References

(Blocks 1 open bug)

Details

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

Attachments

(3 files, 1 obsolete file)

show1.htm
2.25 KB, text/html
Details
Quirks mode body height
175 bytes, text/html
Details
Bug 1259924 - Make the body stretch to the viewport in quirks mode.
47 bytes, text/x-phabricator-request
Details | Review 
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>
 with 

<script type="text/javascript" src="http://www.wsurvey.org/wsurvey/publicLib/jquery-1.11.3.min.js"></script>

I will upload an updated demo in the next comment



Or: just use this..
Flags: needinfo?(danielh)
<html>
<!-- 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="http://www.wsurvey.org/wsurvey/publicLib/jquery-1.11.3.min.js"></script>

<style type="text/css">
.moveC {
   position:fixed;
   left:10%;top:10%;width:70%;height:50%;
   border:2px solid gold;
 }
</style>

<script type="text/javascript">

function init1() {
   $('#mover').mousedown(moveStart);
}


//========  initialze the movement
function moveStart(evt){
  var q1,q1p;
  q1=$('#move0');
  q1p=q1.parent();
  q1.data({'atx':-1,'aty':-1,'left':-1,'top':-1});
  q1p.mousemove(movePos);
  q1p.mouseup(function(){q1p.off('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');
  wasx=q1.data('atx'); wasy=q1.data('aty');       // prior mouse location
  if (wasx<0) {
     q1.data({'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
  gooy=goo.top ; goox=goo.left;

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

  return 1 ;
}
</script>
</head>

<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.

</div>

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

</body>
</html>
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 https://quirks.spec.whatwg.org/
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

    
    

    
  
https://github.com/whatwg/quirks/commit/c81e2a263fb9f89fdfc55010afe666f1711540b7

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 webcompat.com in issue #9045, so it's definitely still affecting sites.
Flags: webcompat?
Flags: needinfo?(dbaron)
See Also:  → https://webcompat.com/issues/9045

    
    

    
  


  
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: --- → ?

    
    

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


Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
See Also:  → 1566699

    
  
OS: Windows 7 → All
Hardware: x86 → All
Webcompat Priority: ? → P3

    
    

    
  


  
I wrote this because I thought it may be the underlying cause of another

compat issue, but it turned out not to be... So I don't plan to land

this right now (it's quite ugly and the compat check may not be right).



    
  
Severity: normal → S3

    
    

    
  
The severity field for this bug is relatively low, S3. However, the bug has 8 duplicates and 5 See Also bugs.

:dholbert, could you consider increasing the bug severity?


For more information, please visit auto_nag documentation.


Flags: needinfo?(dholbert)

    
    

    
  
The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.


Flags: needinfo?(dholbert)
Duplicate of this bug: 1856190
Flags: needinfo?(dbaron)
Blocks: 1890769

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: