Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    URGENT: Tabbing is broken in modal windows

    Version: SmartClient_v82p_2013-02-28
    Browser: IE/FF/Chrome

    Run the test case provided. Click on "Show Window". Click on the first field. Now try to tab out - does not work. Note that we started noticing this issue in Build 2013-02-22 - not sure if it was broken in 2013-02-21 - but it was definitely NOT broken in 2013-01-28

    Code:
    isc.IButton.create({
        ID: "touchButton",
        width: 120,
        title: "Touch This"
    });
    
    isc.Label.create({
        left: 150,
        height: 20,
        contents: "<a href='http://www.google.com' target='_blank'>Open Google</a>"
    });
    
    isc.IButton.create({
        title: "Show Window",
        top: 35,
        left: 75,
        click : function () {
            touchButton.setTitle("Can't Touch This");
            modalWindow.show();
        }
    });
    
    isc.Window.create({
        ID: "modalWindow",
        title: "Modal Window",
        autoSize:true,
        autoCenter: true,
        isModal: true,
        showModalMask: true,
        autoDraw: false,
        closeClick : function () { touchButton.setTitle('Touch This'); this.Super("closeClick", arguments)},
        items: [
            isc.DynamicForm.create({
                autoDraw: false,
                height: 48,
                padding:4,
                fields: [
                    {name: "field1", type: "text"},
                    {name: "field2", type: "text"},
    {name: "field3", type:"text"}
                ]
            })
        ]
    });
    Last edited by acarur01; 28 Feb 2013, 13:39. Reason: Last known working version

    #2
    We've made a change to address this regression.
    Please try the next nightly build (March 2 or greater)

    Thanks
    Isomorphic Software

    Comment


      #3
      Thank you for the update. It works in the March 3rd build but our current product release includes SmartClient_v82p_2013-02-19_PowerEdition - Is it possible to get a patch for this fix on that version? There's a huge gap between 2013-02-19 and 20-13-03-02 and they do not want to take a risk in production.

      Comment


        #4
        Anyone want to answer this?

        Comment


          #5
          The purpose of the "p" suffixed branches is to apply patch-fixes only to a stable codebase. It is always our recommended way to get patches.

          The 8.2p branch builds have very little code motion on it as it is neither our current stable release nor our development branch. We are only applying patches to this branch that are specifically requested by supported customers (or in rare cases if something particularly obvious or severe has been discovered that warrants fixing back to this older branch).
          The differences between the builds you reference (since 2013-01-19) should be minor and consist only of safe bug fixes.

          So we would recommend you upgrade to the latest nightly on the 8.2p branch

          Comment


            #6
            Ok - but you do realize we got to this bug from taking the nightly fixes that are not supposed to have major impact, right? In a CSR perspective, not being able to tab to fields lowers their productivity.

            In any case, I understand that patches are not always doable. We'll communicate with the customer that this build as you mentioned has very little change from the build they originally had. Thanks for the response.

            Originally posted by Isomorphic View Post
            The purpose of the "p" suffixed branches is to apply patch-fixes only to a stable codebase. It is always our recommended way to get patches.

            The 8.2p branch builds have very little code motion on it as it is neither our current stable release nor our development branch. We are only applying patches to this branch that are specifically requested by supported customers (or in rare cases if something particularly obvious or severe has been discovered that warrants fixing back to this older branch).

            Comment


              #7
              Yes, we realize this was a bug introduced by an attempt to patch another bug, sorry about that. This is a rarity and becoming rarer as we add more and more test coverage, but it can happen, especially in areas like focus management where we are already working around clusters of nasty, overlapping browser bugs.

              Regardless, when a patch has subtle side effects, it still makes sense to just get the next build. Hand-created patches can't easily go through the same verification process that builds do, so they actually carry more risk than picking up the next patched build.

              Comment

              Working...
              X