Skip to main content

Bug Tracker

Side navigation

#9410 closed bug (invalid)

Opened May 24, 2011 10:56AM UTC

Closed June 01, 2011 05:32PM UTC

Last modified March 14, 2012 06:23AM UTC

JQuery 1.6.(.1): jquery.event.trigger removed try-catch

Reported by: m.heindl@immowelt.de Owned by: m.heindl@immowelt.de
Priority: undecided Milestone: 1.next
Component: unfiled Version: 1.6.1
Keywords: Cc:
Blocked by: Blocking:
Description

During the massive change in the trigger-function a try-catch block around an if-statement was removed; position at the comment "Trigger an inline bound script".

This causes massive errors from ie6 to ie9 in the combination of triggering a change-event and the clientside eventhandling of asp.net.

We fixed it by simply adding the try-catch again.

try {
 if (ontype && jQuery.acceptData(cur) && cur[ontype] && cur[ontype].apply(cur, data) === false) {
  event.result = false;
  event.preventDefault();
 }
// prevent IE from throwing an error for some elements with some event types, see #3533
} catch (e) { }

Up to version 1.5.2 the comment at the catch was "prevent IE from throwing an error for some elements with some event types, see #3533".

Attachments (0)
Change History (5)

Changed May 24, 2011 12:58PM UTC by dmethvin comment:1

owner: → m.heindl@immowelt.de
status: newpending

Can you provide a test case? The problem with the old code was exactly that the try/catch swallowed errors in a user's inline handlers, so it sounds like the new code is doing just what it should be doing -- allowing users to see errors.

Changed May 24, 2011 01:46PM UTC by m.heindl@immowelt.de comment:2

status: pendingnew

It is quite hard to get a real life test, because we use the asp.net-framework. But here is a little mockup: http://jsfiddle.net/FAG6m/5/

The change-function has quite a similar behavior as our .net-validators in the internet explorer, i.e. trying to access an collection, which is null.

Changed May 24, 2011 07:50PM UTC by dmethvin comment:3

status: newpending

Okay, then use the IE debugger (F12), turn on script debugging, and find out where the error occurs. The call stack and locals should tell you more about the error.

Changed May 25, 2011 09:03AM UTC by m.heindl@immowelt.de comment:4

status: pendingnew

This is the by asp.net autogenerated function, that causes the problems:

function ValidatorOnChange(event) {
    if (!event) {
        event = window.event;
    }
    Page_InvalidControlToBeFocused = null;
    var targetedControl;
    if ((typeof(event.srcElement) != "undefined") && (event.srcElement != null)) {
        targetedControl = event.srcElement;
    }
    else {
        targetedControl = event.target;
    }
    var vals;
    if (typeof(targetedControl.Validators) != "undefined") {
        vals = targetedControl.Validators;
    }
    else {
        if (targetedControl.tagName.toLowerCase() == "label") {
            targetedControl = document.getElementById(targetedControl.htmlFor);
            vals = targetedControl.Validators;
        }
    }
    var i;
    for (i = 0; i < vals.length; i++) {
        ValidatorValidate(vals[i], null, event);
    }
    ValidatorUpdateIsValid();
}

The _selectDate-function of jquery.ui.datepicker triggers the change-event. Between this function and the ValidatorOnChange-function is the usual jquery callstack.

According to the debugger, in IE the targetedControl is filled by event.srcElement. The other Browsers use event.target.

But it has neither validators nor is a label so the variable vals is not filled and is undefined. So vals.length causes the error. It looks as if the function tries to validate the jquery.ui.datepicker itself, because the targetedControl-variable causing the error has no id-attribute and as innerHtml-attribute the number value of the selected day; e.g. picking May, 25th, you geht as innerHtml 25. I think IE validates all html-elements, that have changed, and that causes the problems.

I debugged with IE9 in Browsermodes IE7-9, but all IEs from 6 to 9 have this behavior.

Changed June 01, 2011 05:32PM UTC by dmethvin comment:5

resolution: → invalid
status: newclosed

That seems like a bug in the assumptions of the autogenerated code. The vals variable is not set at all in the case where it fails. Note that code does not seem to be intended to be run under jQuery, it does its own browser feature detects for validation.

In any case, the error does not seem to be anything we should be masking via a try/catch inside jQuery, so I'm going to close this ticket.