Announcement

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

    Issue with SelectItem in Simplicity skin (Verified in showcase)

    Hi all,

    I have an issue with my application where by the bottom option in a select item is covered by scroll bars, this is particularly problematic if there is only one option in the list. The issue only seems to be with the "Simplicity" skin and only if the length of an option is wider than the select item box. Also I'm only aware of the issue effecting chrome but I have not tested all browsers.

    Steps to replicate.

    1) Load the showcase, and use cookie editor to change skin name to "Simplicity"
    2) Load the page http://www.smartclient.com/smartgwt/...bobox_category
    3) Select "Other .." and add the value "Small Value". Expand the list and observe no problem.
    4) Select "Other .." and add the value "Value longer than the display area". Expand the list and observed bottom option is covered by scrollbars

    I hope it is possible to get a fix for this.
    Many Thanks,
    Dale

    ------------------------------------------
    GWT Version : 2.7.0
    SmartGWT Version : 5.0p
    SmartGWT Build Date : 02/07/2015 08:14

    #2
    Hi ellisd5, Hi Isomorphic,

    I have the same problem in my app for ComboBoxItems, but did not file a report, yet. In my case, only Chrome is affected and I think (not at work right now) it only happens when there is only one row to show.
    I'm using v10.0p_2015-08-24 and also a Simplicity based skin.

    Best regards
    Blama
    Last edited by Blama; 2 Sep 2015, 02:20. Reason: Added exact used version

    Comment


      #3
      Thanks for the notification. We'll take a look and follow up when we have more information for you.

      Regards
      Isomorphic Software

      Comment


        #4
        Hi,

        Was just wondering if there was any update on this? At the moment, I'm getting around the issue by overriding a couple of styles...

        div.pickListMenuBody{ overflow: ${compatible.overflow.value} !important; } div.gridBody { overflow: ${compatible.overflow.value} !important; } ${compatible.overflow.value } being replaced with "overlay" for chrome and "auto" for all other browsers but I would obviously a proper fix as I'm a little nervous of an repercussiond of making this change.

        Thanks,
        Dale

        Comment


          #5
          Hi Isomorphic,

          I can also reproduce in this sample by just editing the continent-field (using Simplicity via cookie editor).
          I still see the same issue in my application as well (using GC46 and v10.0p_2015-10-23). Can you reproduce?

          Best regards
          Blama

          Comment


            #6
            We do see the problem here - it's to do with the browsers algorithm for when to show/hide css scrollbars on content change being flawed (or at least having changed) in recent incarnations of some browsers.
            The easy workaround for this issue is to simply add the following to the top of your app (after Simplicity/load_skin.js has been loaded):
            Code:
            isc.Canvas.addProperties({ showCustomScrollbars:true });
            Internally we are still looking at the best solution here - so for now we'd recommend you make this change in application code.

            Regards
            Isomorphic Software

            Comment


              #7
              Hi Isomorphic,

              seeing this post reminded me of this thread.
              I do not have a problem here at my PC (Win10, GC48, FF26), but saw at a product presentation (Mac OS Safari) that the problem is still there.
              I did not try "showCustomScrollbars:true", yet, but would like to have SmartGWT scrollbars, if possible.

              Did you already look into this?

              Best regards
              Blama

              Comment


                #8
                We have switched on custom scrollbars as the new default for Simplicity because WebKit native scrollbars are basically completely broken - they fail to recognize the situation where both scrollbars can be removed, instead thinking that each scrollbar implies the need for the other.

                Comment


                  #9
                  Hi Isomorphic,

                  do you mean for builds from tomorrows on or since some time ago? For all browsers?
                  I'll adjust my skin_styles.css / load_skin.js then once all changes are in.

                  Just to get the terms straight:
                  • native scrollbars = Browsers native scrollbars
                  • custom scrollbars = SmartGWT-StretchImgButton based
                  Why do you say "switched on custom scrollbars"? Per docs this is the default, isn't it? Or wasn't this the case in Simplicity as it tries to use as little media as possible?

                  Best regards
                  Blama

                  Comment


                    #10
                    Those are the correct definitions of the terms.

                    The framework default is to use custom scrollbars, and Simplicity used to override this to use native scrollbars (in load_skin.js) and now no longer does so, since native scrollbars are fundamentally broken for WebKit now.

                    Comment


                      #11
                      Hi Isomorphic,

                      thanks for fixing this. I can see that I have custom scrollbars now in GC and native scrollbars in FF / IE.
                      Just to be sure, this difference is on purpose, correct?

                      load_skin.js code:
                      Code:
                      isc.Canvas.setProperties({
                          // use synthetic scrollbars
                          // in mobile
                          // for Macs, since from OSX Lion onward, scrollbars are not shown by default
                          // in Webkit browsers as css scrollbars are natively shown in some cases when
                          // this should not be necessary
                          showCustomScrollbars:(isc.Browser.isMobile || isc.Browser.isMac ||
                                              !(isc.Browser.isIE || isc.Browser.isFirefox)),
                          ...
                      });
                      Is there a significant performance penalty involved in having custom scrollbars? Because if not, I'll also use custom scrollbars in FF/IE so that the application looks the same.
                      FYI: This comment in the code "// NOTE: not used by default in Simplicity" (line 83) can most likely be removed.

                      Thanks again for analysing and fixing,
                      Blama
                      Last edited by Blama; 8 Apr 2016, 09:24. Reason: Typo: replaced "Simlicity" with "GC"

                      Comment


                        #12
                        Yes, as we keep reiterating, native scrollbars are just broken in WebKit, so we don't have a choice.

                        In general, we recommend using custom scrollbars. Overhead is very minor, arguably they are faster because the many bugs we have to work around with native scrolling.

                        We would also recommend moving to one of the Enterprise-series skins, as they have received a variety of optimizations which we do not plan to apply to Simplicity.

                        Comment


                          #13
                          Hi Isomorphic,

                          good to know - I'll switch to custom scrollbars in all browsers then.
                          I will also definitely base my skin on Enterprise then - when I started my project the recommendation was to base an own skin on Simplicity. I'll have to adapt my changes to Enterprise and will do so once I have the time.

                          Thank you & Best regards
                          Blama

                          Comment

                          Working...
                          X