[ICE-8574] onSubmitSend and onAfterUpdate not being called for certain component actions - ICEsoft JIRA Issue Tracker

Details

Type: Bug
Status: Closed
Priority: Major
Resolution: Fixed
Affects Version/s: 3.2.BETA1, 3.2
Fix Version/s: 3.2, 3.3
Component/s: ACE-Components
Labels:
None
Environment:
All

Assignee Priority:
P1

Description

The onSubmitSend and onAfterUpdate JavaScript events are no longer being called for every server side submit. Examples of this is onchange/blur of an inputText field or the switching of tabs for the ace:tabSet

Options
- Sort By Name
- Sort By Date
- Ascending
- Descending
- Download All

Attachments

Hide
Case11595Example.war

30/Nov/12 11:28 PM

9.47 MB

Migration
META-INF/MANIFEST.MF 0.1 kB

META-INF/context.xml 0.1 kB

WEB-INF/classes/com/.../example/Item.class 0.3 kB

WEB-INF/classes/.../example/TestBean.class 0.7 kB

WEB-INF/lib/commons-beanutils.jar 226 kB

WEB-INF/lib/commons-collections.jar 558 kB

WEB-INF/lib/commons-digester.jar 140 kB

WEB-INF/lib/commons-logging.jar 52 kB

WEB-INF/lib/icefaces-ee-ace.jar 3.02 MB

WEB-INF/lib/icefaces-ee-compat.jar 2.68 MB

WEB-INF/lib/icefaces-ee.jar 337 kB

WEB-INF/lib/javax.faces.jar 2.48 MB

WEB-INF/web.xml 2 kB

resources/js/script.js 0.4 kB

welcomeICEfaces.xhtml 2 kB

Download Zip
Show

Case11595Example.war

30/Nov/12 11:28 PM

9.47 MB

Migration

Activity

Ascending order - Click to sort in descending order

Hide

Permalink

Arran Mccullough added a comment - 17/Sep/12 6:24 PM - edited

This is an issue with the Williams app. They have these events integrated into their notification popup.
(Restricted to icesoft-internal-developers group)

Show

Arran Mccullough added a comment - 17/Sep/12 6:24 PM - edited This is an issue with the Williams app. They have these events integrated into their notification popup. (Restricted to icesoft-internal-developers group)

Hide

Permalink

Arran Mccullough added a comment - 17/Sep/12 6:26 PM - edited

Attached test case that shows issues.

Steps:

Load welcomeICEfaces.jsf
Click on the Test button, the events are correctly executed.
Enter in some text to the input field and tab or focus out. The events are not executed.
Change the displayed tab, again the events are not executed.

Show

Arran Mccullough added a comment - 17/Sep/12 6:26 PM - edited Attached test case that shows issues. Steps: Load welcomeICEfaces.jsf Click on the Test button, the events are correctly executed. Enter in some text to the input field and tab or focus out. The events are not executed. Change the displayed tab, again the events are not executed.

Hide

Permalink

Ken Fyten added a comment - 19/Sep/12 3:43 PM - edited

Need this looked at asap - Mircea is out the rest of this week.
(Restricted to icesoft-internal-developers group)

Show

Ken Fyten added a comment - 19/Sep/12 3:43 PM - edited Need this looked at asap - Mircea is out the rest of this week. (Restricted to icesoft-internal-developers group)

Hide

Permalink

Deryk Sinotte added a comment - 19/Sep/12 5:35 PM - edited

These are the two stack traces for the two registered callbacks in the test case:
Stack Trace for button click (onBeforeSend)

    (anonymous function)       (script.js.jsf:4)
    apply                      (bridge.uncompressed.js.jsf:122)
    (anonymous function)       (bridge.uncompressed.js.jsf:484)
    (anonymous function)       (bridge.uncompressed.js.jsf:363)
    (anonymous function)       (bridge.uncompressed.js.jsf:240)
    broadcast                  (bridge.uncompressed.js.jsf:483)
    (anonymous function)       (bridge.uncompressed.js.jsf:1928)
    options.onevent            (bridge.uncompressed.js.jsf:2243)
    sendEvent                  (jsf.js.jsf:1563)
    AjaxEngine.req.sendRequest (jsf.js.jsf:1454)
    request                    (jsf.js.jsf:1955)
    fullSubmit                 (bridge.uncompressed.js.jsf:2308)
    submit                     (bridge.uncompressed.js.jsf:2313)
    f.onsubmit                 (bridge.uncompressed.js.jsf:2456)

Stack trace for button click (onAfterUpdate)

    (anonymous function)                     (script.js.jsf:10)
    apply                                    (bridge.uncompressed.js.jsf:122)
    (anonymous function)                     (bridge.uncompressed.js.jsf:484)
    (anonymous function)                     (bridge.uncompressed.js.jsf:363)
    (anonymous function)                     (bridge.uncompressed.js.jsf:240)
    broadcast                                (bridge.uncompressed.js.jsf:483)
    (anonymous function)                     (bridge.uncompressed.js.jsf:1940)
    options.onevent                          (bridge.uncompressed.js.jsf:2243)
    sendEvent                                (jsf.js.jsf:1563)
    response                                 (jsf.js.jsf:2200)
    onComplete                               (jsf.js.jsf:1348)
    AjaxEngine.req.xmlReq.onreadystatechange (jsf.js.jsf:1329)

I believe the "sendEvent" function is the key for all these cases. Inside that function is the following logic:

    var sendEvent = function sendEvent(request, context, status) {
    ...
        if (context.onevent) {
            context.onevent.call(null, data);
        }
    ....

With the button, each time this code is run, the onevent callback is set to the function we use to do the callbacks for our APIs:

    context: Object
    formid: "iceForm"
    onerror: function (submitEvent) {
    onevent: function (submitEvent) {
    render: "@all"
    sourceid: "iceForm:_t9"
    __proto__: Object

The full onevent function looks like this:

    function (submitEvent) {
        pageScopedSubmitEventBroadcaster(submitEvent, element);
        requestScopedSubmitEventBroadcaster(submitEvent, element);
    }

For the inputField, when onblur is triggered, onevent is simply false for all status phases (begin, complete, success), so no callbacks are fired:

    context: Object
    formid: "iceForm"
    onerror: false
    onevent: false
    render: "@all"
    sourceid: "iceForm:_t10"
    __proto__: Object

Hitting the Enter key while in the inputText field actually does trigger our event broadcaster.
For the tabs, it's a slightly different problem. There is a function registered with onevent but it's not ours:

    context: Object
    formid: "iceForm"
    onerror: function (submitEvent) {
    onevent: function (I){if(I.status=="success"&&t.newValue==g){v();}}
    render: "@all"
    sourceid: "iceFormyti"
    __proto__: Object

Looks to be a YAHOO function (from ace-yui.js) that replaces ours (the onerror function is still ours):

    function (I){
        if(I.status=="success"&&t.newValue==g){
            v();
        }
    }

Show

Deryk Sinotte added a comment - 19/Sep/12 5:35 PM - edited These are the two stack traces for the two registered callbacks in the test case: Stack Trace for button click (onBeforeSend) (anonymous function) (script.js.jsf:4) apply (bridge.uncompressed.js.jsf:122) (anonymous function) (bridge.uncompressed.js.jsf:484) (anonymous function) (bridge.uncompressed.js.jsf:363) (anonymous function) (bridge.uncompressed.js.jsf:240) broadcast (bridge.uncompressed.js.jsf:483) (anonymous function) (bridge.uncompressed.js.jsf:1928) options.onevent (bridge.uncompressed.js.jsf:2243) sendEvent (jsf.js.jsf:1563) AjaxEngine.req.sendRequest (jsf.js.jsf:1454) request (jsf.js.jsf:1955) fullSubmit (bridge.uncompressed.js.jsf:2308) submit (bridge.uncompressed.js.jsf:2313) f.onsubmit (bridge.uncompressed.js.jsf:2456) Stack trace for button click (onAfterUpdate) (anonymous function) (script.js.jsf:10) apply (bridge.uncompressed.js.jsf:122) (anonymous function) (bridge.uncompressed.js.jsf:484) (anonymous function) (bridge.uncompressed.js.jsf:363) (anonymous function) (bridge.uncompressed.js.jsf:240) broadcast (bridge.uncompressed.js.jsf:483) (anonymous function) (bridge.uncompressed.js.jsf:1940) options.onevent (bridge.uncompressed.js.jsf:2243) sendEvent (jsf.js.jsf:1563) response (jsf.js.jsf:2200) onComplete (jsf.js.jsf:1348) AjaxEngine.req.xmlReq.onreadystatechange (jsf.js.jsf:1329) I believe the "sendEvent" function is the key for all these cases. Inside that function is the following logic: var sendEvent = function sendEvent(request, context, status) { ... if (context.onevent) { context.onevent.call( null , data); } .... With the button, each time this code is run, the onevent callback is set to the function we use to do the callbacks for our APIs: context: Object formid: "iceForm" onerror: function (submitEvent) { onevent: function (submitEvent) { render: "@all" sourceid: "iceForm:_t9" __proto__: Object The full onevent function looks like this: function (submitEvent) { pageScopedSubmitEventBroadcaster(submitEvent, element); requestScopedSubmitEventBroadcaster(submitEvent, element); } For the inputField, when onblur is triggered, onevent is simply false for all status phases (begin, complete, success), so no callbacks are fired: context: Object formid: "iceForm" onerror: false onevent: false render: "@all" sourceid: "iceForm:_t10" __proto__: Object Hitting the Enter key while in the inputText field actually does trigger our event broadcaster. For the tabs, it's a slightly different problem. There is a function registered with onevent but it's not ours: context: Object formid: "iceForm" onerror: function (submitEvent) { onevent: function (I){ if (I.status== "success" &&t.newValue==g){v();}} render: "@all" sourceid: "iceFormyti" __proto__: Object Looks to be a YAHOO function (from ace-yui.js) that replaces ours (the onerror function is still ours): function (I){ if (I.status== "success" &&t.newValue==g){ v(); } }

Hide

Permalink

Mircea Toma added a comment - 26/Sep/12 1:09 PM - edited

Modified ICEfaces callback invocation behavior. Now ICEfaces specific callbacks are invoked when the view is ICEfaces enabled, regardless of the function used to submit the form.

Show

Mircea Toma added a comment - 26/Sep/12 1:09 PM - edited Modified ICEfaces callback invocation behavior. Now ICEfaces specific callbacks are invoked when the view is ICEfaces enabled, regardless of the function used to submit the form.

Hide

Permalink

Ken Fyten added a comment - 26/Sep/12 5:45 PM - edited

In IE7 I'm getting JS errors when navigating to any sample page (no errors in other browsers):

1) Expected identifier, string or number
2) 'log' is null or not an object
3) Object doesn't support this property or method
4) 'configuration.disableDefaultErrorPopups' is null or not an object

Show

Ken Fyten added a comment - 26/Sep/12 5:45 PM - edited In IE7 I'm getting JS errors when navigating to any sample page (no errors in other browsers): 1) Expected identifier, string or number 2) 'log' is null or not an object 3) Object doesn't support this property or method 4) 'configuration.disableDefaultErrorPopups' is null or not an object

Hide

Permalink

Deryk Sinotte added a comment - 22/Feb/13 10:15 PM

So I ran the test case as it stands and could see the originally reported issue. Then I swapped out the libraries and used the latest from the icefaces3/trunk (rev 33566) then re-ran the test using Chrome, IE 9 (in IE9/8/7 modes), as well as a "real" copy of IE7 and everything worked fine for me. I didn't see any JS errors and the popups came up as expected.

I also checked against the official 3.2 libs and everything seems to work fine there.

Show

Deryk Sinotte added a comment - 22/Feb/13 10:15 PM So I ran the test case as it stands and could see the originally reported issue. Then I swapped out the libraries and used the latest from the icefaces3/trunk (rev 33566) then re-ran the test using Chrome, IE 9 (in IE9/8/7 modes), as well as a "real" copy of IE7 and everything worked fine for me. I didn't see any JS errors and the popups came up as expected. I also checked against the official 3.2 libs and everything seems to work fine there.

People

Assignee:

Deryk Sinotte

Reporter:

Arran Mccullough

Votes:

0 Vote for this issue

Watchers:

2 Start watching this issue

Dates

Created:

17/Sep/12 6:22 PM

Updated:

14/Nov/14 5:38 PM

Resolved:

22/Feb/13 10:15 PM