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

click event is generated twice for buttons using the canvas renderer #108

Closed
wants to merge 2 commits into from

Conversation

aurhe
Copy link
Contributor

@aurhe aurhe commented Oct 4, 2013

When using a DOM renderer the element that generates the "mousedown" event is different from the element that generates the "mouseup" event because of the different button states (up/down). Therefore it is necessary to manually fire the "click" event. But if the used renderer is canvas, it's the same element for both button states and the "click" event ends up being fired twice.

@tonistiigi
Copy link
Member

How can I reproduce the double click? I tested the button2 demo that has a button with a canvas renderer but it seemed to work just fine.

I doubt the difference comes from different dom elements for the states because Lime does not listen events on separate dom elements, only for the container.

@aurhe
Copy link
Contributor Author

aurhe commented Oct 7, 2013

I've just tested it and the button action seems to be stopping the second event. In that test instead of replacing the scene on the button action do a console.log or something like that, it should print twice to the console.

@krscott
Copy link

krscott commented Oct 13, 2013

(In case this hasn't made progress) I'm getting the same problem. The 2 events are actually different, the second one being more like a normal mouse event, with many more fields. My quick workaround is to filter out the second event:

goog.events.listen(myButton, 'click', function (e) {
  if (e.event) {
    return; // Ignore dummy event
  }
  // actual event handling ...
}

More detail:
The first event object has the following fields:

currentTarget: myNamespace.MyButton
target: myNamespace.MyButton
type: "click"

The second event, which is not fired when DOM-rendering, has the following fields:

clone: function () {
currentTarget: myNamespace.MyButton
dispatcher_: lime.events.EventDispatcher
event: goog.events.BrowserEvent
identifier: 0
position: goog.math.Coordinate
release: function (opt_type) {
screenPosition: goog.math.Coordinate
startDrag: function (snapToCenter, box,
swallow: function (type, handler, opt_deny_shared) {
target: myNamespace.MyButton
targetObject: myNamespace.MyButton
type: "click"

@ghost ghost assigned tonistiigi Oct 13, 2013
@stringa
Copy link
Contributor

stringa commented Oct 29, 2013

I am seeing this with a DOM renderer in the current codebase. I am trying to debug this now. Click seems to be fired twice. The normal click event from the browser, and the overridden click from 'button'.

If i modify the events enum such that lime.Button.Event.CLICK === 'buttonClick', everything is working again.

The problem seems to be that the browser 'click' is getting fired and a custom click is also dispatched from a button on 'mouseup'.

Still trying to figure out the real fix for this.

stringa

@aurhe
Copy link
Contributor Author

aurhe commented Dec 19, 2013

I still can't see this happening with the DOM renderer in the current codebase.
But lime.Button.Event.CLICK = 'buttonClick' does indeed also fixes it.
If it is ok with you I can remove the previous commits and add this.

tonistiigi added a commit that referenced this pull request Dec 19, 2013
@tonistiigi
Copy link
Member

I landed the buttonClick fix. If someone finds a better fix then send new PR.

@tonistiigi tonistiigi closed this Dec 19, 2013
@aurhe aurhe deleted the canvas_button_fix branch December 20, 2013 09:53
@tonistiigi
Copy link
Member

This is still an issue and better fix is needed. Current implementation is very confusing. Codebase is still full of "click" event handlers(as literal strings) and for some reason they even work in Chrome. #120 is probably also just related to the renaming.

I'm now in favor or keeping the "click" name. It would help to get some test cases about duplicate dispatches so I could tackle down the real issue here.

tonistiigi added a commit that referenced this pull request Feb 24, 2014
@tonistiigi
Copy link
Member

I reverted the commit but can't reopen the issue for some reason.

tonistiigi added a commit that referenced this pull request Oct 10, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants