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

Cesium captures all mouse and touch events which doesn't bubble up document.activeElement #10185

Open
cmcleese opened this issue Mar 10, 2022 · 7 comments

Comments

@cmcleese
Copy link

All mouse and touch events are capture during viewer init.
The focus events do occur when trying to change focus from a different non Cesium UI element to Cesium canvas.
Basically if a NON Cesium UI element has focus and we try to unfocus from that element by clicking on the Cesium canvas, the unfocus event cannot work correctly.
Cesium is capturing these events and thus not bubbling to allow for changing of the document.activeElement

EX: https://codesandbox.io/s/test-quasar-cesium-vue3-edjxls?file=/src/index.template.html

Oddly this doesn't appear to be an issue with Firefox. Only Chromium browsers.

This should be consistent with all browsers.
See example above in both browsers to notice the issue.

Browser: Firefox, Chrome

Operating System: windows

@ggetz
Copy link
Contributor

ggetz commented Mar 10, 2022

Thanks for the report @cmcleese. If I understand correctly, this is the same issue as #9134. Is that correct?

@cmcleese
Copy link
Author

Hi @ggetz, yes this does sound very similar.
However this seems to affect any element which was set via document.activeElement.
I can also believe it was a relatively recent code change that change the way this behavior is handled.
Not quite sure exactly which version yet however.

@ggetz
Copy link
Contributor

ggetz commented Mar 14, 2022

I see, thanks @cmcleese.

To help get to the root of the change in behavior, would you be able to track down in what version this changed? If you're familiar with git, git bisect is a helpful tool for finding the exact commit in which things changed.

@yonzmeer
Copy link
Contributor

yonzmeer commented Jun 28, 2022

Hi.
I am the author of the similar issue you mentioned.
As I wrote in my issue, the pr that broke the behavior was (#8662)

My idea was to make this behavior configurable via the ViewerConstructorOptions - so the blurActiveElement function will not be passed for the addEventListener.

I can open such pr if you think this is an acceptable solution.

@cmcleese
Copy link
Author

I have not been able to come up with any alternative in my testing.
Currently using hack fix to emulate keypress 'esc' event to get captured event blurred.

@ggetz
Copy link
Contributor

ggetz commented Jun 30, 2022

My idea was to make this behavior configurable via the ViewerConstructorOptions - so the blurActiveElement function will not be passed for the addEventListener.

Thanks for the interest in contributing @yonzmeer. That should be fine so long as the default behavior remains the same when this option is not provided.

@yonzmeer
Copy link
Contributor

yonzmeer commented Jul 6, 2022

My idea was to make this behavior configurable via the ViewerConstructorOptions - so the blurActiveElement function will not be passed for the addEventListener.

Thanks for the interest in contributing @yonzmeer. That should be fine so long as the default behavior remains the same when this option is not provided.

Opened one. Would love some help with it, especially with my naming.

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

3 participants