Announcement

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

    Did 3.1 break ListGridField#setHeaderBaseStyle in IE9?

    With SmartGWT 3.1 2012-12-20 ListGridField#setHeaderBaseStyle does not remove the standard header background in IE9. A known issue?

    Code:
    field.setHeaderBaseStyle("someNonExistentStyle");
    removes the background (image) in FF but not in IE9 (see listgrid-header-base-style.png).

    Here's a standalone code sample that tries to resemble my actual case:

    Code:
    public class SmartGwt implements EntryPoint {

  public void onModuleLoad() {
    ListGrid listGrid = createListGrid();
    listGrid.setFields(createFields());
    listGrid.addData(new Record());
    HLayout canvas = new HLayout();
    canvas.addMember(listGrid);
    canvas.draw();
  }
  
  private ListGrid createListGrid() {
    ListGrid listGrid = new ListGrid();
    listGrid.setBorder("0");
    listGrid.setWidth(300);
    listGrid.setCanReorderFields(Boolean.FALSE);
    listGrid.setShowHeaderContextMenu(Boolean.FALSE);
    listGrid.setAutoFitWidthApproach(AutoFitWidthApproach.BOTH);
    listGrid.setShowRecordComponents(Boolean.TRUE);
    listGrid.setShowRecordComponentsByCell(Boolean.TRUE);
    listGrid.setAlternateRecordStyles(Boolean.FALSE);
    listGrid.setShowHeader(Boolean.TRUE);
    listGrid.setCanSort(Boolean.FALSE);
    listGrid.setCanResizeFields(Boolean.FALSE);
    listGrid.setCanEdit(Boolean.TRUE);
    listGrid.setHeight(48);
    listGrid.setAlwaysShowEditors(Boolean.TRUE);
    listGrid.setNeverValidate(Boolean.TRUE);
    listGrid.setEditByCell(Boolean.TRUE);
    listGrid.setAutoFitData(Autofit.VERTICAL);
    listGrid.setBodyOverflow(Overflow.VISIBLE);
    listGrid.setOverflow(Overflow.VISIBLE);
    listGrid.setLeaveScrollbarGap(Boolean.FALSE);
    listGrid.setShowAllRecords(Boolean.TRUE);
    listGrid.setSelectionType(SelectionStyle.NONE);
    listGrid.setCanTabToHeader(Boolean.FALSE);
    listGrid.setAnimateRemoveRecord(Boolean.FALSE);
    listGrid.setFastCellUpdates(Boolean.FALSE);
    return listGrid;
  }
  
  private ListGridField[] createFields() {
    List<ListGridField> allFields = new ArrayList<ListGridField>();
    ListGridField regularField = new ListGridField("test", "Test", 200);
    allFields.add(regularField);
    allFields.add(createAddRemoveColumn());
    return allFields.toArray(new ListGridField[allFields.size()]);
  }
  
  protected ListGridField createAddRemoveColumn() {
    ListGridField addRemoveField = new ListGridField("someField", " ", 24);
    addRemoveField.setCanEdit(Boolean.FALSE);
    addRemoveField.setType(ListGridFieldType.ICON);
    addRemoveField.setCellIcon("http://www.smartclient.com/smartgwt/showcase/images/silk/comment_edit.png");
    addRemoveField.setShowHover(Boolean.TRUE);
    
    Map<String, String> icons = new HashMap<String, String>();
    addRemoveField.setValueIcons(icons);
    addRemoveField.setHeaderButtonProperties(createAddButton());
    addRemoveField.setHeaderBaseStyle("someNonExistentStyle");
    
    return addRemoveField;
  }
  
  private Button createAddButton() {
    Button button = new Button();
    button.setIcon("http://www.smartclient.com/smartgwt/showcase/images/silk/chart_bar.png");
    button.setTooltip("Foo");
    button.setPadding(2);
    button.setIconHeight(16);
    button.setIconWidth(16);
    button.setShowDown(Boolean.FALSE);
    button.setShowRollOver(Boolean.FALSE);
    return button;
  }
}
    Attached Files
    Last edited by fhisg; 30 Jan 2013, 02:09.
    Tags: None
    #2
    More tests show that this is another quirks vs. standards issue with IE9 (updated the test case, too). It works fine in Firefox standards and almost with IE9 quirks (see difference to FF) but not in IE9 standards.
    Last edited by fhisg; 1 Feb 2013, 02:02.

    Comment

      #3
      Sorry to bump this, but it's been sitting idle for nearly a month. Just in case you're interested in the bootstrap HTML and the .gwt.html, here they are:

      [html]
      <!-- quirks -->
      <!DOCTYPE HTML>
      <html>
      <head>
      <script type="text/javascript" src="smartgwt/smartgwt.nocache.js"></script>
      </head>
      <body>
      </body>
      </html>
      [/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"/>
  <inherits name="com.smartgwt.tools.SmartGwtTools"/>  
  <entry-point class='com.corp.smartgwt.client.SmartGwt'/>
</module>
      It's the same test bed as with my recent SelectItem issue.

      Comment

        #4
        This would appear to be a result of the fact that in IE9, quirks mode, the header buttons for the ListGrid are StretchImgButton based whereas in Firefox they're Button based.
        This is set up via ListGrid.headerButtonConstructor, and depending on the skin being loaded may be set up, varying by browser in load_skin.js.

        You should be able to get the behavior you want via one of the following options:

        - set the headerTitleStyle for the field. This will effect the text displayed over the header button only - it won't update the image loaded behind this text

        - set headerButtonConstructor explicitly to "Button" for this ListGrid [will effect all buttons, so you'll need to ensure you have appropriate looking css styles loaded. You can add customizations to all buttons via listGrid.headerButtonProperties if necessary]

        - use ListGridField.setHeaderButtonProperties() to further customize the button.

        Let us know if that doesn't give you enough to get the desired behavior

        Comment

          #5
          Ok, I'll test and analyze. Could you maybe describe what the respective changes between 3.0 and 3.1 in this area are? This used to work just fine with 3.0 before upgrading...

          Comment

            #6
            Originally posted by Isomorphic View Post
            - set headerButtonConstructor explicitly to "Button" for this ListGrid [will effect all buttons, so you'll need to ensure you have appropriate looking css styles loaded. You can add customizations to all buttons via listGrid.headerButtonProperties if necessary]
            What is headerButtonConstructor? The Javadoc for ListGrid.getHeaderTitleStyle() does mention it but there are no methods for this property. Furthermore, the docs also point to GridHeader which mentions respective methods but without links. In the latest 3.1p build I see no methods for headerButtonConstructor...

            Originally posted by Isomorphic View Post
            - use ListGridField.setHeaderButtonProperties() to further customize the button.
            We're already doing that. See createAddButton() in the provided test case. Calling button.setBackgroundImage(""); in that method has no noticeable effect because the gray gradient doesn't come from the button background.

            Comment

              #7
              headerButtonConstructor is a skinning property used in JavaScript inside load_skin.js. See the Skinning Guide for further details, but the nutshell is that such properties are looking up in the SmartClient reference (right here).

              Also a side note - we stated that the headerButtonConstructor was "StretchImgButton" by default in browsers that don't support css3, but it is in fact "ImgButton". Sorry for the confusion - this is a setting that varies by skin.

              Comment

                #8
                Originally posted by Isomorphic View Post
                headerButtonConstructor is a skinning property used in JavaScript inside load_skin.js.
                Ok, now it all makes sense. The value for headerButtonConstructor changed from Button to ImgButton from 3.0 to 3.1. I tried reverting that in my load_skin.js but the result was terrible. I doubt I'll be able to fix all the CSS in order to make it look like what it used to be.

                The real issue here (apart from this being a regression bug) seems to be that ListGridField.headerBaseStyle is not applied. In the test case I do addRemoveField.setHeaderBaseStyle("someNonExistentStyle"); but someNonExistentStyle is nowhere to be found in the DOM. Were it applied as it should I'd have a chance to hide the img inside the imgHeaderButton div. Please run the test and take a look at base-style-not-applied.png.
                Attached Files

                Comment

                  #9
                  To understand why you're not seeing your baseStyle you need to understand the structure written out for ImgButtons.
                  ImgButtons and stretchImg buttons are actually rendered as 2 components.
                  The ImgButton itself is a standard widget with the specified "baseStyle" applied to its handle, and with an HTML <img ...> tag written into this handle with src set to the appropriate URL.
                  As such the baseStyle is written into the DOM but if the img is not transparent, things like background color / background image won't be visible since the actual <img ...> tag sits on top of this handle.

                  The title is written into a separate Label component that is automatically generated and floats over the ImgButton handle. This has the "titleStyle" for the widget applied to it.
                  You can therefore perform style customization for the title text using the titleStyle for the ImgButton.

                  If you want to change the image in some ImgButton, you should use the src attribute. Note that setting this to null would hide the image entirely, but you would likely see some (actually harmless) warnings in the logs as you interact with buttons as it attempts to update the src of an image that has not been written out.

                  On the broader issue of whether it would be possible to go back to using Button rather than ImgButton based header buttons, we are looking into it and will let you know if we decide to move back to "Button" in browsers where css3 is not available (such as IE9 quirks mode, and older versions of IE and other browsers).

                  Comment

                    #10
                    Thanks for the thorough explanation. I had figured it out by looking at the generated HTML source before but it's good to see my assumptions confirmed.

                    Still, there seems to be a misunderstanding. It's not that my headerBaseStyle is not applied, the respective CSS class is never written into the DOM (the handle div) as far as I can see.

                    We call
                    Code:
                    addRemoveField.setHeaderBaseStyle("someNonExistentStyle");
                    but as you can see in the screen shot attached to the previous post the handle's class is 'imgHeaderButton' which is the default I suppose. I also searched the entire DOM for 'someNonExistentStyle' but the IE returned nothing. Were our base style really written to the DOM it'd be possible to hide the ImgButton <img> with CSS alone.

                    What I had in mind:
                    Code:
                    div.someNonExistentStyle {
  border: 0;
  background: none;
}
div.someNonExistentStyle img {
  display: none;
}

                    Comment

                      #11
                      That does seem odd. It's hard for us to be certain from the screenshot but from some internal tests, the field-level headerBaseStyle attribute should be correctly assigning the style to the header button.
                      Can you try the following:
                      - ensure that your call to setHeaderBaseStyle() on the field is called before the field is passed to the listGrid via "setFields()"
                      - within the loaded application, you should be able to see the ID of the header button in the developer console. If you click the header you'll see the ID as the "last mouseDown target" in the dev console. It will likely be something like "isc_ImgButton_0". If you evaluate "isc_ImgButton_0.baseStyle", you should see your specified style being picked up at the widget level.
                      - you can also evaluate isc_ImgButton_0.getStateName() to see the state name (should be the base style, plus any additional modifiers such as "Selected").
                      - you can also evaluate isc_ImgButton_0.getClipHandle() to get at the actual DOM element in question. Looking at the "className" attribute of that should tell you what css class has been applied.

                      This should confirm for certain whether your base style is getting picked up.

                      Comment

                        #12
                        Originally posted by Isomorphic View Post
                        It's hard for us to be certain from the screenshot
                        That's why I started this thread with a full test case ;-)

                        The results are odd (odd=I don't get it). The column header in question is a Button and not an ImgButton although it is rendered like an ImgButton. Maybe that is because we invoke

                        Code:
                            addRemoveField.setHeaderButtonProperties(createAddButton());
    ...
private Button createAddButton() {
    Button button = new Button();
    ....
                        The column header in the "regular" column i.e. the left column is an ImgButton. So, here's the output for isc_Button_0:

                        Code:
                        >> isc_Button_0.baseStyle 
"someNonExistentStyle" 
>> isc_Button_0.getStateName() 
"someNonExistentStyle" 
>> isc_Button_0.getClipHandle().className 
"imgHeaderButton"

                        Comment

                          #13
                          It's been nearly a week, any news?

                          Comment

                            #14
                            We've been working on this and finally believe we have it fixed
                            (Turned out to be a trivially simple change in an unexpected place that took a long time to track down)

                            Please try the next nightly build and let us know if the specified style persists in not showing up

                            Thanks
                            Isomorphic Software

                            Comment

                              #15
                              Works for us, thanks.

                              Comment

                              Previous template Next
                              Working...
                              X