Announcement

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

    load_skin.js Issue in SmartClient 9.0

    Hi,

    We have an issue about the different behavior for sectionheader in IE10 and FF12. We notice that in IE10, the sectionHeaderClass is "ImgSectionHeader" while in FF12, the sectionHeaderClass is "SectionHeader". After tracing the code and checking the load_skin.js in Enterprise skin, we found that FF12 is using the "useCSS3" branch of code which doesn't set "sectionHeaderClass:'ImgSectionHeader'".
    This breaks our selenium test cases since the sectionheader class changes from "ImgSectionHeader" to "SectionHeader".

    Can you please take a look at it? We are using SmartClient v9.0p_2013-11-20 build.

    Thanks!

    #2
    You should be using CSS3 mode in both browsers. That's the default. You probably broke this by not using the HTML5 DOCTYPE, which is also required for IE9+ (see FAQ).

    Note also, your Selenium tests should not be relying on CSS classnames, since those differ by skin and sometimes by browser or browser version. This is part of the point our extensive Selenium support, which uses locators which do not depend on the DOM structure.

    So, while in this instance the classNames will end up the same once you have switched to CSS3 mode for both browsers, in general, different CSS classNames for different browsers would not have been considered a bug.

    Comment


      #3
      Thanks for your quick response and explanation.

      Our selenium test cases came from 8.2. We directly get the autotest locator from SmartClient and we didn't add the Class name to it.

      For example, in FF12 for the Sections-> Add and Remove example in feature explorer, the autotest locator for the first section header shown in the console is
      "//SectionStack[ID="sectionStack"]/section[Class=ImgSectionHeader||index=0||length=3||classIndex=0||classLength=3||roleIndex=0||roleLength=3||title=Blue%20Pawn||scRole=heading||name=section0]/background/" in SmartClient_v82p_2013-03-04 build but the it changes to
      "//SectionStack[ID="sectionStack"]/section[Class=SectionHeader||index=0||length=3||classIndex=0||classLength=3||roleIndex=0||roleLength=3||title=Blue%20Pawn||scRole=heading||name=section0]/" in SmartClient v9.0p_2013-11-20.

      The locator change fails many of our test cases and we consider it as a backward compatibility issue.

      Thanks!

      Comment


        #4
        Locators are not expected to be identical between versions, skins, etc. If you are comparing locators as part of a test, that's incorrect usage.

        The purpose of locators is to retrieve the same logical element even in a different browser, version of SmartClient, skin, etc. And the locator from 8.2 will still find the equivalent element in 9.0 and beyond, because it contains name, title, and index information that it will use first; classname is a last-ditch fallback.

        Comment


          #5
          Thanks for the explanation.
          Just need to clarify the case: Do we still need to check and modify locators, directly generated by selenium IDE with the given smartCilent extension, to remove the skin related information? (e.g. Class= ImgSectionHeader in this case).

          BTW, the locator in 8.2 ends with "/background/" but in 9 it doesn't. Is this also a skin related issue? Even we remove the "Class=" condition, this extra "/background/" still prevent us using the same selenium statement to test in different versions.

          Thanks.

          Comment


            #6
            Originally posted by ESherbakova View Post
            Just need to clarify the case: Do we still need to check and modify locators, directly generated by selenium IDE with the given smartCilent extension, to remove the skin related information? (e.g. Class= ImgSectionHeader in this case).
            No. Also, we're not sure why you say "still", as you have not had to do this in the past.

            BTW, the locator in 8.2 ends with "/background/" but in 9 it doesn't. Is this also a skin related issue?
            Not a skin issue per se, but yes the new, simpler widget should be accepting that locator as well. We'll fix this.

            Comment


              #7
              Thanks for the clarification. We really appreciate it.

              Comment


                #8
                We've added fixes for the /background/ locator issue to SC 8.3p, 9.0p, and 9.1d that should make it into the next nightlies.

                Comment


                  #9
                  Thanks for the fix. It works fine on v9.0p_2013-12-02 build.

                  We notice a similar locator change for the SliderItem.

                  In 8.3 when we click the slider's horizontal bar, the locator has an extra "stretch" at the end but in 9.0 it is not there, which fails our test cases.

                  If we take the "Number - Slider" example in feature explorer as example, in 8.3 the locator is
                  "//FeatureExplorer[ID="featureExplorer"]/exampleViewer/exampleViewPane[Class=ExampleViewPane||index=0||length=1||classIndex=0||classLength=1]/viewContainer/child[Class=DynamicForm||index=0||length=1||classIndex=0||classLength=1]/item[name=rating||title=Rating||value=4||index=0||Class=SliderItem]/canvas/track[Class=StretchImg||index=0||length=1||classIndex=0||classLength=1]/stretch"
                  but in 9.0 it changes to
                  "//FeatureExplorer[ID="featureExplorer"]/exampleViewer/exampleViewPane[Class=ExampleViewPane||index=0||length=1||classIndex=0||classLength=1]/viewContainer/child[Class=DynamicForm||index=0||length=1||classIndex=0||classLength=1]/item[name=rating||title=Rating||value=4||index=0||Class=SliderItem]/canvas/track[Class=StatefulCanvas||index=0||length=1||classIndex=0||classLength=1]/"
                  Can you please take a look at it? Thanks!
                  Last edited by Isomorphic; 4 Dec 2013, 14:26.

                  Comment


                    #10
                    Just a quick note to let you know we see the problem. We'll follow up when we have a resolution in place

                    Regards
                    Isomorphic Software

                    Comment


                      #11
                      We've made a change which we believe should address this issue. Please try the next nightly build, dated Dec 6 or above

                      Regards
                      Isomorphic Software

                      Comment


                        #12
                        Thanks! This issue is fixed on Dec 6th's build.

                        Comment

                        Working...
                        X