2012-07-11 11 views
6

echar un vistazo a este jsFiddleMouseEnter/eventos MouseLeave no disparar a los elementos SVG utilizando jQuery.on

El mouseenter/mouseleave no parecen ser disparando correctamente cuando se utiliza en conjunción con jQuery SVG (Rafael 2.0). Sé de antemano que SVG jQuery no es 100% compatible con SVG, sin embargo, por lo que puedo ver, parece que solo afecta a IE9.

Lo extraño es que mueva rápidamente el mouse dentro/fuera del elemento svg (asegurándose de salir directamente del panel de HTML) y de nuevo los eventos se disparan (pero no siempre). Solo para asegurarme de que no era un problema general con on conecté el evento click que funciona bien, siempre.

¿Se pregunta si alguien sabe si esto es un error o incluso un problema conocido?

+0

funciona para mí (cromo) –

+0

@StefanFandler - "* por lo que puedo ver, parece afectar IE9 *". Etiquetado para aclaración. – James

+0

Evito usar jQuery junto con SVG como la peste. Es un campo minado lleno de excepciones como esta. Creo que su error está relacionado con este http://forum.jquery.com/topic/1-6-2-broke-svg-hover-events (no resuelto desde hace dos años). – Duopixel

Respuesta

2

Esto es un error en 1.7.2. Ver ticket.

El problema desaparece si utilizo jQuery (edge), por lo que se debe corregir en la próxima versión programada (1.8).

0

Creo que es importante tener en cuenta que con jQuery 1.8.2 y Android a través de phonegap no se utiliza jq-mobile. Estoy viendo eventos táctiles y de mouse seleccionados aleatoriamente y no sincronizados ... significa diferencia sutil desencadenar mouseIntroducir y hacer clic en comparación con un toque táctil diferente touchStart (a veces, si aún no se ha enviado un mouseEnter) y luego 2 touchEnds. Si tiene un touchEvent activa un mouseEnter el segundo patrón táctil (inicio, final, final) envía un mouseLeave (suponiendo que no al azar a través de sutiles diferencias de toque desencadenar un clic combo).

Mi expectativa era que se activen juntas en ambas situaciones, excepto una (eventos táctiles) se usa más para necesidades múltiples, o para reconocer que no va a haber un evento mouseLeave después de un evento click simulado a través de una interfaz táctil (¿de algun modo?...). Mi otra expectativa sería si no proceso o no tengo un oyente registrado para los eventos del mouse, pero sí para los eventos táctiles y viceversa, diferentes eventos serían o no enviados según lo escuchado o interceptado (¿devuelve falso? o para dejar de burbujear mediante preventDefault, etc.).

De todos modos, me parece que actualmente necesita manejar ambos tipos de eventos de forma aleatoria e impredecible, lo que para mí significa descartar lo que en un mundo de mouse se describe mejor como eventos 'sobre' en dispositivos con capacidad táctil.

Básicamente, estoy pensando que un toque no debería enviar un evento de sobre/ingresar, mientras que un clic también debe tocarse, y si estoy escuchando para tocar preventDefault debería cancelar dicho mouseEvents.

De todos modos, tiene más sentido enviar ambos y dejar que lo resuelva. La confusión que sospecho es que solo escuchas la mitad de los eventos que está enviando (toque faltante). ... ¡así que buena suerte! Es posible que esos pensamientos ayuden a alguien a lidiar con el problema, ya sea en el nivel superior o en los equipos de desarrollo de nivel inferior. (¿Es el nivel del navegador a quien culpar? Creo que sí.)

Cuestiones relacionadas