ICEfaces
  1. ICEfaces
  2. ICE-5947

Regression Icefaces2 - ICE-4288 Click Action & Click Listener are not fired on IE browser only

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0-Beta2
    • Fix Version/s: 2.0-Beta2
    • Component/s: None
    • Labels:
      None
    • Environment:
      Server: Tomcat6
      IE browser only
    • Assignee Priority:
      P1

      Description

      Icefaces2 revision#22029

      Load application and click on any row id the table
      Notice the clickAction & clickListener are not fired (text 'click action fired' or 'click listenerfired' is not displayed)

      Test-case available at 'C:\repo\qa\trunk\Regression-Icefaces2\Nightly\ICE-4288'

        Activity

        Mandeep Hayher created issue -
        Mandeep Hayher made changes -
        Field Original Value New Value
        Assignee Deryk Sinotte [ deryk.sinotte ]
        Hide
        Deryk Sinotte added a comment -

        A fix for a previous regression may have resolved this issue as I was not able to replicate the problem. I the action and listener are both fired when clicking on a row.

        Show
        Deryk Sinotte added a comment - A fix for a previous regression may have resolved this issue as I was not able to replicate the problem. I the action and listener are both fired when clicking on a row.
        Deryk Sinotte made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Fix Version/s 2.0-Beta2 [ 10242 ]
        Resolution Fixed [ 1 ]
        Hide
        Deryk Sinotte added a comment -

        Re-opening because the problem does manifest on IE but some caching can lead to misleading results (ie the page will work if you previously ran a working version and then re-deployed a non-working version). So once I cleared the cache between each redeployment, I could see the issue reliably.

        This behaviour is a result of the compat resync work in http://jira.icefaces.org/browse/ICE-5252). IE works fine in rev 22018 but fails in 22019 which is the checking for the noted case.

        I did a diff of the rendered source in the browser between the two revisions and discovered to notable differences:

        Difference #1, there is an extra semicolon at the very end of the non-working source:

        r22019
        <tr class="iceDatTblRow1 iceRowSel" id="iceForm:dataTbl:0" onclick="Ice.registerClick(this,'iceForm:dataTblclick_row','iceForm:dataTblclick_count','0','iceForm',200,true,event,false,'iceForm:dataTblsel_rows','');" ondblclick="Ice.registerDblClick(this);" onmousedown="return Ice.preventTextSelection(event);" onmouseout="Ice.enableTxtSelection(document.body); this.className='iceDatTblRow1 iceRowSel'" onmouseover="this.className=' iceRowSelMouseOver';">

        vs

        r22018
        <tr class="iceDatTblRow1 iceRowSel" id="iceForm:dataTbl:0" onclick="Ice.registerClick(this,'iceForm:dataTblclick_row','iceForm:dataTblclick_count','0','iceForm',200,true,event,false,'iceForm:dataTblsel_rows','');" ondblclick="Ice.registerDblClick(this);" onmousedown="return Ice.preventTextSelection(event);" onmouseout="Ice.enableTxtSelection(document.body); this.className='iceDatTblRow1 iceRowSel'" onmouseover="this.className=' iceRowSelMouseOver'">

        Difference #2, there is an extra anchor rendered out in the non-working source that is not in the working source. It occurs in the first cell/column of each row only.

        r22019 only
        <a class="iceHdnLnk" href="#" id="iceForm:dataTbl_idx_0" onblur="return Ice.tblRowBlur(this);" onfocus="return Ice.tblRowFocus(this, false);">
        <img src="/ICE-4288/xmlhttp/css/xp/css-images/spacer.gif" />
        </a>

        Show
        Deryk Sinotte added a comment - Re-opening because the problem does manifest on IE but some caching can lead to misleading results (ie the page will work if you previously ran a working version and then re-deployed a non-working version). So once I cleared the cache between each redeployment, I could see the issue reliably. This behaviour is a result of the compat resync work in http://jira.icefaces.org/browse/ICE-5252 ). IE works fine in rev 22018 but fails in 22019 which is the checking for the noted case. I did a diff of the rendered source in the browser between the two revisions and discovered to notable differences: Difference #1, there is an extra semicolon at the very end of the non-working source: r22019 <tr class="iceDatTblRow1 iceRowSel" id="iceForm:dataTbl:0" onclick="Ice.registerClick(this,'iceForm:dataTblclick_row','iceForm:dataTblclick_count','0','iceForm',200,true,event,false,'iceForm:dataTblsel_rows','');" ondblclick="Ice.registerDblClick(this);" onmousedown="return Ice.preventTextSelection(event);" onmouseout="Ice.enableTxtSelection(document.body); this.className='iceDatTblRow1 iceRowSel'" onmouseover="this.className=' iceRowSelMouseOver';"> vs r22018 <tr class="iceDatTblRow1 iceRowSel" id="iceForm:dataTbl:0" onclick="Ice.registerClick(this,'iceForm:dataTblclick_row','iceForm:dataTblclick_count','0','iceForm',200,true,event,false,'iceForm:dataTblsel_rows','');" ondblclick="Ice.registerDblClick(this);" onmousedown="return Ice.preventTextSelection(event);" onmouseout="Ice.enableTxtSelection(document.body); this.className='iceDatTblRow1 iceRowSel'" onmouseover="this.className=' iceRowSelMouseOver'"> Difference #2, there is an extra anchor rendered out in the non-working source that is not in the working source. It occurs in the first cell/column of each row only. r22019 only <a class="iceHdnLnk" href="#" id="iceForm:dataTbl_idx_0" onblur="return Ice.tblRowBlur(this);" onfocus="return Ice.tblRowFocus(this, false);"> <img src="/ ICE-4288 /xmlhttp/css/xp/css-images/spacer.gif" /> </a>
        Deryk Sinotte made changes -
        Resolution Fixed [ 1 ]
        Status Resolved [ 5 ] Reopened [ 4 ]
        Hide
        Deryk Sinotte added a comment -

        Still not sure what's causing this. Looks to be JavaScript related as single clicking doesn't register but double-clicking appears to work fine.

        Show
        Deryk Sinotte added a comment - Still not sure what's causing this. Looks to be JavaScript related as single clicking doesn't register but double-clicking appears to work fine.
        Hide
        Deryk Sinotte added a comment -

        I've narrowed this down a bit more once I got the JavaScript debugging working in IE8.

        The re-sync of the compat components was not done 100% due to the complexity of the some of the changes. So some component changes and some bridge changes were not applied. The problem I am seeing is related to event.js in that when the mouse is clicked on a row, the event is being detected in the following method as a NetscapeMouseEvent rather than an IEMouseEvent:

        function $event(e, element) {
        var capturedEvent = window.event || e;
        if (capturedEvent && capturedEvent.type) {
        var eventType = 'on' + capturedEvent.type;
        if (contains(KeyListenerNames, eventType))

        { return window.event ? IEKeyEvent(event, element) : NetscapeKeyEvent(e, element); }

        else if (contains(MouseListenerNames, eventType))

        { //The following line is returning a NetScapeMouseEvent when running in IE return window.event ? IEMouseEvent(event, element) : NetscapeMouseEvent(e, element); }

        else

        { return window.event ? IEEvent(event, element) : NetscapeEvent(e, element); }

        } else

        { return UnknownEvent(element); }

        }

        In checking the 1.8 trunk, I noticed there is a fair amount of difference in the event adapting code compared to the 2.0 library. So it's likely that, due to the incomplete porting, there is some behavioural difference in what is being passed in or how the event is detected.

        Show
        Deryk Sinotte added a comment - I've narrowed this down a bit more once I got the JavaScript debugging working in IE8. The re-sync of the compat components was not done 100% due to the complexity of the some of the changes. So some component changes and some bridge changes were not applied. The problem I am seeing is related to event.js in that when the mouse is clicked on a row, the event is being detected in the following method as a NetscapeMouseEvent rather than an IEMouseEvent: function $event(e, element) { var capturedEvent = window.event || e; if (capturedEvent && capturedEvent.type) { var eventType = 'on' + capturedEvent.type; if (contains(KeyListenerNames, eventType)) { return window.event ? IEKeyEvent(event, element) : NetscapeKeyEvent(e, element); } else if (contains(MouseListenerNames, eventType)) { //The following line is returning a NetScapeMouseEvent when running in IE return window.event ? IEMouseEvent(event, element) : NetscapeMouseEvent(e, element); } else { return window.event ? IEEvent(event, element) : NetscapeEvent(e, element); } } else { return UnknownEvent(element); } } In checking the 1.8 trunk, I noticed there is a fair amount of difference in the event adapting code compared to the 2.0 library. So it's likely that, due to the incomplete porting, there is some behavioural difference in what is being passed in or how the event is detected.
        Deryk Sinotte made changes -
        Salesforce Case []
        Assignee Priority P1
        Assignee Deryk Sinotte [ deryk.sinotte ] Mircea Toma [ mircea.toma ]
        Hide
        Deryk Sinotte added a comment -

        So just double checking with the debugger shows that the window.event is not set which causes the check to fall back to an NetscapeMouseEvent which in turn short circuits the rest of the submission.

        Show
        Deryk Sinotte added a comment - So just double checking with the debugger shows that the window.event is not set which causes the check to fall back to an NetscapeMouseEvent which in turn short circuits the rest of the submission.
        Hide
        Deryk Sinotte added a comment -

        I think I've exhausted what I can do here so have assigned to Mircea. Hopefully it's relatively easy to repair/update the changes from the re-sync of the compat components. IE is also showing a problem in Component Showcase where the collapsible panels aren't working but I think it is likely related to this issue as well.

        Show
        Deryk Sinotte added a comment - I think I've exhausted what I can do here so have assigned to Mircea. Hopefully it's relatively easy to repair/update the changes from the re-sync of the compat components. IE is also showing a problem in Component Showcase where the collapsible panels aren't working but I think it is likely related to this issue as well.
        Deryk Sinotte made changes -
        Salesforce Case []
        Hide
        Deryk Sinotte added a comment -

        The JIRA for the collapsible panel is: http://jira.icefaces.org/browse/ICE-5949

        Show
        Deryk Sinotte added a comment - The JIRA for the collapsible panel is: http://jira.icefaces.org/browse/ICE-5949
        Repository Revision Date User Message
        ICEsoft Public SVN Repository #22080 Wed Aug 04 08:05:56 MDT 2010 mircea.toma ICE-5947 Modify the browser type detection for the decorated events.
        Files Changed
        Commit graph MODIFY /projects/bridge-support/src/main/javascript/event.js
        Hide
        Mircea Toma added a comment -

        It seems that the table component Javascript is capturing the 'onclick' event and invokes iceSubmitPartial() function on a separate thread (using a setTimeout). This confuses the browser detection used for wrapping the original event into an IEEvent or NetscapeEvent type because 'window.event' global variable is not set by the browser anymore at the time the setTimeout executes.
        Since window.event is missing the detection code falsely assumes that the browser is not IE and it can decorate the event with the NetscapeEvent object type.

        The fix changes the event detection by testing for event properties that exist only in IE and also for properties that should not exist if the browser is IE.

        Show
        Mircea Toma added a comment - It seems that the table component Javascript is capturing the 'onclick' event and invokes iceSubmitPartial() function on a separate thread (using a setTimeout). This confuses the browser detection used for wrapping the original event into an IEEvent or NetscapeEvent type because 'window.event' global variable is not set by the browser anymore at the time the setTimeout executes. Since window.event is missing the detection code falsely assumes that the browser is not IE and it can decorate the event with the NetscapeEvent object type. The fix changes the event detection by testing for event properties that exist only in IE and also for properties that should not exist if the browser is IE.
        Mircea Toma made changes -
        Status Reopened [ 4 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Hide
        Mandeep Hayher added a comment -

        Tested successfully on Icefaces2 revision# 22099
        Passed in nightly regression test.

        Show
        Mandeep Hayher added a comment - Tested successfully on Icefaces2 revision# 22099 Passed in nightly regression test.
        Mandeep Hayher made changes -
        Status Resolved [ 5 ] Closed [ 6 ]

          People

          • Assignee:
            Mircea Toma
            Reporter:
            Mandeep Hayher
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: