Announcement

Collapse
No announcement yet.
X
Collapse
  • Page of 2
  • Filter
  • Time
Clear All
new posts
Previous 1 2 template Next
    #1

    Two issues with 3.1 SelectItem

    With SmartGWT 3.1 2012-12-20 we're seeing two issues with SelectItem that are hard to describe with words or images. Therefore, I made a screen video: http://frightanic.com/misc/selectitem.mp4.
    • with IE9 scrolling through the pick list shows an odd effect that seems somehow related to the dotted/dashed border, the selected item seems to shift up/down by 1(?) pixel
    • opening/closing the pick list causes two scroll bars to be rendered (no matter what the window size actually is)


    Here's the sample code used in the video:

    Code:
    public class SelectItemTest extends HLayout {

  public SelectItemTest() {
    setMargin(20);

    TextItem text = new TextItem("text", "Title");

    SelectItem selectItem = new SelectItem("select", "Select");
    LinkedHashMap<String, String> valueMap = new LinkedHashMap<String, String>();
    for (String value : new String[]{"Foo", "Bar", "Else"}) {
      valueMap.put(value, value);
    }
    selectItem.setValueMap(valueMap);
    
    DynamicForm form = new DynamicForm();
    form.setFields(text, selectItem);

    addMember(form);
  }
}
    Tags: None
    #2
    This kind of thing can happen if you add third-party CSS to the page.

    Make sure there's no CSS other than that provided by SmartGWT in the page, and test with a default skin.

    If you're still seeing the issue at that point, indicate what skin it happens in as well as what DOCTYPE is in use for the page.

    Comment

      #3
      Originally posted by Isomorphic View Post
      This kind of thing can happen if you add third-party CSS to the page.

      Make sure there's no CSS other than that provided by SmartGWT in the page, and test with a default skin.
      Grrrr, sorry about that. In my test HTML (see below) I still had one custom CSS rule which I missed. Removing it fixes the "picklist over issue". However, I need a way of setting the picklist font-size to 13px. That's what clashes with your default skin.

      Code:
      .pickListMenuBody td {
  font-size: 13px !important;
}
      Originally posted by Isomorphic View Post
      If you're still seeing the issue at that point, indicate what skin it happens in as well as what DOCTYPE is in use for the page.
      The "picklist open then two scrollbars" issue, however, has nothing to do with custom CSS. It's still there...

      Here's my test HTML:

      Code:
      <html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <meta http-equiv="Pragma" content="no-cache" />
    <meta http-equiv="Cache-Control" content="no-cache" />
    <meta http-equiv="Expires" content="Thu, 01 Dec 1994 16:00:00 GMT" />
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    <meta name="gwt:property" content="locale=de_CH"/>
    <title>SmartGwt</title>
    <script type="text/javascript" src="smartgwt/smartgwt.nocache.js"></script>
    <script type="text/javascript" src="http://maps.googleapis.com/maps/api/js?v=3.4&sensor=false"></script>
    <link rel="shortcut icon" type="image/x-icon" href="images/favicon.ico" />
    <meta http-equiv="X-UA-Compatible" content="IE=7" />
  </head>
  <body>
    <iframe title="historyFrame" src="javascript:''" id="__gwt_historyFrame" style="position:absolute;width:0;height:0;border:0"></iframe>
  </body>
</html>

      Comment

        #4
        Use listGrid.baseStyle, controllable via pickListProperties, to influence styling of picklist rows.

        You've got your page in XHTML mode, which is incorrect (we use HTML5 not XHTML). Remove the xmlns attribute, and we also recommend adding the HTML5 DOCTYPE ("<!DOCTYPE html>")

        Comment

          #5
          Originally posted by Isomorphic View Post
          Use listGrid.baseStyle, controllable via pickListProperties, to influence styling of picklist rows.
          The results are getting more weird.

          Code:
          ListGrid pickListProperties = new ListGrid();
pickListProperties.setBaseStyle("myBaseStyle");
selectItem.setPickListProperties(pickListProperties);

.myBaseStyle, .myBaseStyleOver, .myBaseStyleSelected {
  font-size: 13px;
}
          Renders picklist rows with various font sizes (see picklist-basestyle.png). Also, I don't intend to style the rows from scratch, I just need a bigger font. In any case it's something that changed from 3.0 to 3.1.

          Originally posted by Isomorphic View Post
          You've got your page in XHTML mode, which is incorrect (we use HTML5 not XHTML). Remove the xmlns attribute, and we also recommend adding the HTML5 DOCTYPE ("<!DOCTYPE html>")
          I know that, but I'm trying to show that it simply doesn't have an impact on the described behavior. I tried various combinations. Using

          Code:
          <!-- Quirks -->
<!DOCTYPE HTML>
<html>
          still triggers the scroll bars. This too changed from 3.0 to 3.1.
          Attached Files

          Comment

            #6
            The font size problem in the PickList is because you have alternateRecordStyles enabled but haven't provided styles with a "Dark" suffix.

            The scrollbar problem obviously doesn't happen in samples - it may be due to Google maps. Let us know if you isolate the cause and it seems to be a SmartGWT bug.

            Comment

              #7
              Originally posted by Isomorphic View Post
              The font size problem in the PickList is because you have alternateRecordStyles enabled but haven't provided styles with a "Dark" suffix.
              Finally, after another 30min trial-and-error there's light at the end of the tunnel. I noticed that for Firefox you use the base style 'pickListCell'. So, in order to get consistent behavior across browsers I need the following:

              Code:
              ListGrid pickListProperties = new ListGrid();
pickListProperties.setBaseStyle("pickListCell");
selectItem.setPickListProperties(pickListProperties);
              and

              Code:
              .pickListCell, .pickListCellSelected, .pickListCellSelectedDark, .pickListCellDark {
  font-size: 13px;
}
.pickListCellSelected, .pickListCellSelectedDark {
  background-image: none !important;
  background-color: <some-color> !important;
}
              However, this only works if I omit

              Code:
              border-bottom: #9fb7e9 dotted 1px;
border-top: #9fb7e9 dotted 1px;
              in my CSS - you added this to the CSS for 3.1. If this is included I get the same behavior as seen in the video. To conclude, the top/bottom dotted border causes problems with IE9 if the font-size is increased from 11px to 13px.

              Originally posted by Isomorphic View Post
              The scrollbar problem obviously doesn't happen in samples - it may be due to Google maps. Let us know if you isolate the cause and it seems to be a SmartGWT bug.
              Yes, yes and yes. Not in the showcase, not in Firefox, not with SmartGWT 3.0. As previously said it's with in IE9 after upgrading from 3.0. Just run the included test case. It's not because of Google Maps.
              Last edited by fhisg; 23 Jan 2013, 00:19.

              Comment

                #8
                If you set different size borders in the normal vs rollover state the contents will shift in IE because the borders make the cells taller.

                Once again, this doesn't happen in samples, and neither does the effect of having scrollbars on the whole page.

                You haven't actually provided an actual test case - just an .html bootstrap that had issues, and some code that's a subclass, clearly part of a bigger app.

                So you should *really* try running with just the SDK and minimal code with no CSS customizations - you will be able to verify this problem doesn't occur, then you can return to finding out the actual cause.

                Finally, just in case: make sure you are not zoomed, and disable any extensions you might have installed in your browser.

                Comment

                  #9
                  Originally posted by Isomorphic View Post
                  If you set different size borders in the normal vs rollover state the contents will shift in IE because the borders make the cells taller.
                  Thanks, I'll give this a try.

                  Originally posted by Isomorphic View Post
                  You haven't actually provided an actual test case - just an .html bootstrap that had issues, and some code that's a subclass, clearly part of a bigger app.
                  Back to the scrollbar issue...

                  When is a test case a test case? I can't paste the Eclipse project here. The .html included a CSS which it shouldn't have - I changed this after your first reply. I told you I had tested different doctypes and that it didn't make a difference. Same with the Google Maps JS import. The code isn't part of a bigger app, it's the only thing running in my SmartGWT test-bed. I use it in order to....write test cases for my issues (and keep the old stuff).

                  Code:
                  public class SmartGwt implements EntryPoint {
  public void onModuleLoad() {
    new SelectItemTest().draw();
  }
}
                  Anyway, here's all again without the stuff that has no impact.

                  Code:
                  public class SelectItemTest extends HLayout {
  public SelectItemTest() {
    SelectItem selectItem = new SelectItem("select", "Select");
    LinkedHashMap<String, String> valueMap = new LinkedHashMap<String, String>();
    for (String value : new String[]{"Foo", "Bar", "Else"}) {
      valueMap.put(value, value);
    }
    selectItem.setValueMap(valueMap);
    DynamicForm form = new DynamicForm();
    form.setFields(selectItem);
    addMember(form);
  }
}
                  Code:
                  <html>
  <head>
    <script type="text/javascript" src="smartgwt/smartgwt.nocache.js"></script>
    <meta http-equiv="X-UA-Compatible" content="IE=7" />
  </head>
  <body>
  </body>
</html>
                  Code:
                  <?xml version="1.0" encoding="UTF-8"?>
<module rename-to='smartgwt'>
  <inherits name='com.google.gwt.user.User'/>
  <inherits name="com.smartgwt.SmartGwt"/>
  <entry-point class='com.comp.smartgwt.client.SmartGwt'/>
  <set-property name="user.agent" value="ie6,gecko1_8" />
  <extend-configuration-property name="document.compatMode" value="BackCompat" />
</module>
                  I cannot stress often enough that this sounds like a 3.1 regression bug in IE9 to me. I can run the same code with 3.0 and all is well.

                  Comment

                    #10
                    Just to jump in here briefly --

                    We've encountered several issues with IE9 that are not problems in the other browsers. Best as we can tell, it's an issue with IE's native HTML rendering (for example, you can't resize grid columns in IE9). We've been able to get around it by enforcing compatibility mode. It will ignore any CSS3 styles (like rounded corners), but those are probably rarely used.

                    Go into your base HTML file and add this tag after the <head> tag:

                    Code:
                    <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE8">
                    That will force the browser to IE8 mode. See if that helps.

                    Comment

                      #11
                      Do not follow this advice. Follow the advice in the FAQ of using the HTML5 DOCTYPE.

                      If you have some kind of IE-specific bug, post about it here, providing everything needed to reproduce the problem.

                      In particular, this claim of grid resizing issues doesn't seem to be happening in the Showcase, and one would expect a lot of people reporting it if it were really a bug..

                      Comment

                        #12
                        A test case is (as explained in the FAQ) code that can be run into one of the sample projects in the SDK by just dropping it in.

                        This eliminates all possibilities that there is something special in your environment.

                        Note that the point is for *you* to actually test that way (not just to write us something that *should* run in an unmodified SDK, because, in this case, the expectation is that when you try your code in a plain SDK, the problem will disappear (since it's not happening in samples).

                        Then you can take a careful look at what's different about your environment.

                        Comment

                          #13
                          Originally posted by Isomorphic View Post
                          If you have some kind of IE-specific bug, post about it here, providing everything needed to reproduce the problem.
                          My last attempt... you keep telling me to report here if I think this is a (regression) bug and provide information to support that claim. Yet, I've been nothing but doing that from the beginning - at least that was my intention.

                          The presented code works with GWT 2.4 and SmartGWT 3.0 2012-11-01, has been working throughout 2012 with various nightlies. It doesn't work (i.e. scroll bars) in IE9 with GWT 2.4 and SmartGWT 3.1 2012-12-20 or 2013-01-23. When stuff breaks while upgrading from version n to n+1 I think it'd be nothing but fair to at least consider it may be a regression.

                          I packed up the artifacts posted in my previous post in a standalone Eclipse project: http://www.frightanic.com/misc/SmartGwt.zip. You just need to correct the classpath, point to your SmartGWT JAR.
                          Last edited by fhisg; 24 Jan 2013, 06:31.

                          Comment

                            #14
                            Once again, we don't look at Eclipse projects, which can have many, many random errors in them. A standalone test case is code that runs in a standard SDK project - generally, just one Java file with code in onModuleLoad().

                            This is not an unusual or challenging requirement, and it's what the FAQ tells you to do - so no need for multiple attempts, just start with what the FAQ says, and you're done in one step.

                            Comment

                              #15
                              Code:
                              public class SelectItemTest implements EntryPoint {

  @Override
  public void onModuleLoad() {
    HLayout layout = new HLayout();
    SelectItem selectItem = new SelectItem("select", "Select");
    LinkedHashMap<String, String> valueMap = new LinkedHashMap<String, String>();
    for (String value : new String[]{"Foo", "Bar", "Else"}) {
      valueMap.put(value, value);
    }
    selectItem.setValueMap(valueMap);
    DynamicForm form = new DynamicForm();
    form.setFields(selectItem);
    layout.addMember(form);
    layout.draw();
  }
}

                              Comment

                              Previous 1 2 template Next
                              Working...
                              X