IOS safari BUG Summary

IOS safari BUG Summary
IOS safari BUG summary safari has a strange BUG in the bubble mechanism of elements in the DOM, which can only be triggered in iOS versions ~~~ For the BUG reproduction case, see Online DEMO: Address bug performance and avoidance. When entrusting an event, if the element event that does not exist in the DOM is directly delegated to the body, the event Delegate will fail, the debugging result is that the event is returned to the body sub-element, neither bubbling to the body nor being captured by the body. However, if the event is a DOM element, it will not trigger a bug. In other words, this bug is triggered only when non-standard events of elements (such as the click event to div. The bug is caused by the event parsing mechanism of safari and cannot be repaired. However, there are multiple ways to avoid triggering the bug: Do not delegate the bug to the body node, delegate to any specified parent element, or use the native element with this event. For example, if triggered by the click event, use the tag to package a layer. How to fix the event that has been triggered: safari parses the event very specially. If an event has been responded, it will always bubble (capture) to the root node. Therefore, for scenarios that have been triggered on a large scale, you only need to bind an empty event to all the child elements of the body element, for example, ("body> *"). on ("click", function () {};); may have some impact on performance, but it is easy to use. You can weigh it out ~~~ Some people think that the third parameter addEventListener can be used to control event delegation. In fact, event bubbling has little to do with the delegation mechanism. Many people think that the third parameter is used to control whether the event is bubbling to the root node. In fact, from the official explanation, its role is to control whether event triggering is in the capture or bubble phase. That is to say, if the event bubble mechanism does not exist at all, the event Delegate can still be completed. Why? There are also event capturing. In addition, this is the W3C standard. Originally, there was no bubble. For some purposes that everyone understands, IE reversed the capture process to "CREATE" the bubble mechanism. Therefore, the event response mechanism is actually: capture from the outside to the inside-> event of the element itself-> bubble from the inside to the outside. Therefore, the stopPropagation () method is not only for bubbling, but also for event capture. In short, it is to prevent events from being distributed to other nodes, it is responded by other nodes. However, for some historical reasons, although the specification clearly requires that the capture phase will not involve event targets, however, IE9, Safari, Chrome, Firefox, Opera9.5, and later will trigger events on the event object in the capture phase. The result is that there are two opportunities to operate events on the target object.