Skip to main content

Bug Tracker

Side navigation

#504 closed bug (fixed)

Opened December 14, 2006 05:52PM UTC

Closed January 03, 2007 05:10PM UTC

Last modified June 19, 2007 07:00AM UTC

Event handling error messages in Safari with 1.0.4

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

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


The effect continues to work, by the way.

Attachments (0)
Change History (11)

Changed December 21, 2006 03:51PM UTC by brandon comment:1

priority: minorcritical

I've done some testing on this bug and the source is the 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:

Changed December 22, 2006 02:01PM UTC by joern comment:2

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; =;
event = clone;

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

Changed December 22, 2006 10:21PM UTC by brandon comment:3

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.

Changed December 22, 2006 11:38PM UTC by joern comment:4

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?

Changed December 23, 2006 05:26PM UTC by john comment:5

milestone: → 1.1
version: 1.01.1

Changed December 23, 2006 06:02PM UTC by brandon comment:6

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

Changed December 24, 2006 07:49AM UTC by comment:7

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?

Changed December 24, 2006 04:16PM UTC by joern comment:8

Good idea. Implementation may look like this:

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

Changed December 24, 2006 05:00PM UTC by brandon comment:9

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

Changed December 26, 2006 05:15PM UTC by brandon comment:10

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:

Changed January 03, 2007 05:10PM UTC by brandon comment:11

resolution: → fixed
status: newclosed

This is now fixed in SVN REV: 817