Bug Tracker

Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#504 closed bug (fixed)

Event handling error messages in Safari with 1.0.4

Reported by: warp@… Owned by:
Priority: critical Milestone: 1.1a
Component: event Version: 1.1a
Keywords: Cc:
Blocked by: Blocking:

Description

I today upgraded the internal development version of our site from jQuery 1.0.3 to jQuery 1.0.4.

We use following simple snippet to get a certain :hover effect for our tables:

$("table.ruler tbody tr,table.ruler > tr").hover(
             function(e) { $(this).addClass("ruled"); return true; },
             function(e) { $(this).removeClass("ruled"); return true; }
            );

This continues to function but spams the Safari JavaScript error console with following error message if the mouse pointer hovers above a text link within the table. Type error jquery.js Line: 1036

(line number in reference to jQuery 1.0.4 in the uncompressed version). This maybe is some problem with the event-object fixer for Safari.

The effect continues to work, by the way.

Change History (11)

comment:1 Changed 13 years ago by brandon

Priority: minorcritical

I've done some testing on this bug and the source is the event.target fix we applied for Safari by cloning the event object. Apparently, Safari's native event methods are expecting something from the event object that the cloned object doesn't have and failing.

I'm am continuing my testing here: http://brandon.jquery.com/testing/504/

comment:2 Changed 13 years ago by joern

How about... using the original event object as the prototype to the clone, and adding only the correct target to the clone. Something like this:

var clone = {};
clone.prototype = event;
clone.target = event.target.parentNode;
event = clone;

I haven't much experience with prototype usage, but this should be worth a try.

comment:3 Changed 13 years ago by brandon

I went ahead and tried a few variations of the above but nothing would work. I even tried creating a new event and initializing it with the document.createEvent and event.initEvent but could not get anything to work properly.

comment:4 Changed 13 years ago by joern

Ok, so we want to fix the target property without spamming the console. Can you track down where the exception is thrown, so that we can swallow it?

comment:5 Changed 13 years ago by john

Milestone: 1.1
Version: 1.01.1

comment:6 Changed 13 years ago by brandon

Yeah the problem is when trying to call event.preventDefault() or event.cancelBubble(). These two native event methods require something from the original event object that isn't copied over to the clone. So this means that an event that spawns from a nodeType of 3 cannot be canceled nor can its default be prevented. This is a problem that should probably be solved before we move onto 1.1

comment:7 Changed 13 years ago by warp@…

What if you just "wrap" the original event object in the new object, assign it to some field there and provide custom preventDefault() and cancelBubble() functions which call the appropriate functions in the original object?

comment:8 Changed 13 years ago by joern

Good idea. Implementation may look like this:

// Check safari and if target is a textnode
if ( jQuery.browser.safari && event.target.nodeType == 3 ) {
	// target is readonly, clone the event object
	var originalevent = event;
	event = jQuery.extend({}, originalevent);
	// get parentnode from textnode
	fakeevent.target = event.target.parentNode;
	fakeevent.preventDefault = function() {
		originalevent.preventDefault();
	}
	fakeEvent.stopPropagation = function() {
		originalevent.stopPropagation;
	}
}

comment:9 Changed 13 years ago by brandon

Good idea warp@… ... I'll see if I can find some time to try this out tonight.

comment:10 Changed 13 years ago by brandon

This is working thus far but when I read out the event properties it is throwing an error for some reason. I'm going to track that down and put the patch here and post to SVN.

Testing still ongoing here: http://brandon.jquery.com/testing/504/

comment:11 Changed 13 years ago by brandon

Resolution: fixed
Status: newclosed

This is now fixed in SVN REV: 817

Note: See TracTickets for help on using tickets.