Attach empty onclick listener to each node

[sophiebits]

Fixes #1169, fixes #238.

This is a more robust way of fixing what MobileSafariClickPlugin previously tried to. Now even if you don't want anything to do with touch events, click events still work properly.

Test Plan: Added a click handler to an <img /> element and triggered it in the iOS simulator -- it didn't execute before.

cc @yungsters

[yungsters]

Very nice... I like this a lot more.

[yungsters]

What do you think about naming this didPutListener? Haha, lifecycle methods for everyone.

[sophiebits]

Fine with me; I was feeling uncreative. :)

[sophiebits]

Renamed to didPutListener and willDeleteListener.

[facebook-github-bot]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks!

[syranide]

Perhaps wait for decision on #1550, which could allow for it to be done very cheaply.

[sophiebits]

Didn't your analysis conclude that walking the tree is already fast and so this should be fine as is?

[syranide]

@spicyj Seems so yes, I was thinking that it might be easier to fix it in ReactDOMComponent or something similar, seeing as it will have "zero-cost" access to the node. So it's possible that the event API will be trimmed/reworked slightly in the end, as we can now either attach directly to the DOM or query the ReactDOMComponents instead, cheaply.

Will probably be a long time coming though, so perhaps its better to just go ahead with this.

[sophiebits]

Yeah, we should merge this for now -- if we decide to change how event handlers are done in general later then we can do that.

[yungsters]

This is not used.

[sophiebits]

Oops, fixed. We have really got to get linting properly working here…

[syranide]

Accidentally posted it in the wrong PR (this is the right one):

http://www.quirksmode.org/blog/archives/2010/09/click_event_del.html

Apart from its ugliness, I see one problem with this approach: if my guess is right and
the Apple engineers have in fact disabled click event delegation because of memory
considerations, this workaround will create new memory problems. Lots of them if you
have lots of divs that must become clickable.

But that can’t be helped. Event delegation simply must work for the click event, and if
we have to brute-force it at the expense of memory that’s just too bad for Safari iPhone.

An alternative is to force cursor: pointer on Mobile Safari, since you can't see the cursor no one should care, it only has to exist for that element with a click-handler and it should keep us away from the issue above? I think? (It does have to play nice with style though, which might not be trivial?)

[sophiebits]

I believe that the reason this is required is simply so that Safari can show the active style on the right element; you want each "distinct" clickable element to highlight separately, but you don't want subelements to get highlighted by themselves if they go to the same place as their siblings.

I can only assume that cursor: pointer would have the same overhead and I prefer this solution as it doesn't require browser sniffing or otherwise messing with CSS.

[syranide]

Hmm, true. The current implementation explicitly and immediately traverses the DOM to all the affected elements, which is something we want to avoid in the general case I would think. I'm not opposed to it, but if we're committed to keeping the node cache lazy, it seems counter-productive to have more and more elements explicitly traverse the DOM on insertion anyway (which requires more logic = slightly more expensive).

Also, yeah, cursor: pointer would still have to traverse the DOM and I was under the impression that onclick="" would need to be added to all elements on the path, which it doesn't seem like it does?

[sophiebits]

No, you only want to add onclick="" to the element that has the handler.