Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Window mousedown/mouseup events no longer fire in Chrome #4768

Closed
pjcozzi opened this issue Dec 20, 2016 · 6 comments
Closed

Window mousedown/mouseup events no longer fire in Chrome #4768

pjcozzi opened this issue Dec 20, 2016 · 6 comments

Comments

@pjcozzi
Copy link
Contributor

pjcozzi commented Dec 20, 2016

Window mousedown/mouseup events no longer fire in Chrome 55. I also tested Canary with the same result.

The events do fire in Firefox.

This is not a new issue in Cesium; I tested Cesium 1.28, 1.25, and 1.20 with the same results.

var viewer = new Cesium.Viewer('cesiumContainer');

window.addEventListener('mousedown',function(e) {
    console.log('mouse down');
});
                        
window.addEventListener('mouseup',function(e) {
    console.log('mouse up');
});

window.addEventListener('click',function(e) {
    console.log('mouse click');
});


viewer.screenSpaceEventHandler.setInputAction(function(e){ 
    //window.addEventListener('mouseup',function(e) { 
        console.log('Left down');        
    }, Cesium.ScreenSpaceEventType.LEFT_DOWN);

@emackey any idea? Is this a new Chrome bug? Or a fix to Chrome that revealed a bug in Cesium? Sandcastle specific (I also tested in a new window).

@hpinkos
Copy link
Contributor

hpinkos commented Dec 20, 2016

Related #4767?

@pjcozzi
Copy link
Contributor Author

pjcozzi commented Dec 20, 2016

Is this related to #4126?

@emackey
Copy link
Contributor

emackey commented Feb 8, 2017

Chrome added support for pointerevents, which Edge and IE11 already have. I wouldn't be surprised to see Firefox introduce them as well. We already support pointerevents to be able to support touch (and pen) interactions in IE & Edge, so Cesium listens for and handles the pointerevents.

Unfortunately this means your old mousedown event is obsolete. On browsers supporting pointer events, old-school mousedown is only fired as a fallback for when the real pointer event went unhandled by the page.

The correct solution is to use viewer.screenSpaceEventHandler as shown at the bottom of the sample code above, since that goes to the trouble of detecting pointer and touch events as well as old mouse events. If you want to use the raw native JavaScript events, your app code will need to have paths to handle at least pointer events and likely touch events as well.

The browser is still willing to fire old mousedown events for non-Cesium elements on the page, but only because those elements don't have pointer event handlers wired up to them. We can't offer that to apps that want raw mouse interactions on the Cesium canvas itself, since we already made the jump to pointer events.

Long story short: Upgrade your app's event handling. Use the ScreenSpaceEventHandler or another polyfill, or roll your own event handling that includes pointer events, but don't just bind to old-school mousedown and expect the Cesium canvas to fire that, it's obsolete.

@emackey emackey closed this as completed Feb 8, 2017
@mramato
Copy link
Contributor

mramato commented Feb 8, 2017

Use the ScreenSpaceEventHandler or another polyfill,

I strongly recommend users always use https://github.com/jquery/PEP in any Cesium application, this will enable pointer events in all browsers for consistent behavior. Cesium can't do this itself since we don't want to pollute the global namespace. I recommend against using ScreenSpaceEventHandler in client apps because it doesn't buy you anything over using pointer events directly.

@emackey
Copy link
Contributor

emackey commented Feb 8, 2017

I have no problem recommending PEP over ScreenSpaceEventHandler for client apps. But for situations where PEP is not welcome, ScreenSpaceEventHandler is a fine choice, and offers you this functionality:

  • It handles native pointer, touch, and mouse events, and detects which ones are meaningful.
  • It remembers locations of "other" touches/pointers, for example if pointer 2 is on the move it keeps track of where pointer 1 is, which raw pointer events don't do (but raw touches do).
  • It processes certain gestures, notably "pinching", and reports on that at a higher level than raw events or polyfills will provide.

It does have a few warts as well, for example it registers and prevents default even on unhandled actions. But ever since it added support for pointer events, it became valuable in its own right, more than just a simple polyfill, and I think it's wrong to mark it private or try to steer users away from it.

@mramato
Copy link
Contributor

mramato commented Feb 8, 2017

@emackey while I agree with you, my longer-term goal is actually to make ScreenSpaceEventHandler private because we don't really want to support it as a general input handler for client apps.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants