ICEfaces
  1. ICEfaces
  2. ICE-8746

ace:submitMonitor - WebKit styling issue when blockUI is set to an id

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.2
    • Fix Version/s: EE-3.2.0.GA
    • Component/s: ACE-Components
    • Labels:
      None
    • Environment:
      Chrome, Safari

      Description


      A submitMonitor has it's blockUI attribute set to a panelGroup which holds a dataTable, this dataTable is where the submit comes from (via pagination). The submitMonitor also has it's for attribute set to the same panelGroup. In this scenario, no overlay is present and the submitMonitor renders slightly off center. This is Chrome and Safari browsers only.
      To reproduce:
      1) Build / deploy test application located at: http://server.ice:8888/svn/repo/qa/trunk/Regression-Icefaces2/Sparkle/Manual/submitMonitor
      2) In Chrome, navigate to '/submitMonitorFor.jsf'
      3) Scroll down to the test at the bottom (ace:dataTable with ace:ajax 'page' event)
      4) Change the blockUI to 'panelGroup5'
      5) Trigger submitMonitor busy state using the dataTable pagination
      6) Notice no overlay can be seen on the page and the submitMonitor is not centered.

      This is a spin-off of issue #2 from ICE-8669 into its own jira.

        Activity

        Hide
        Mark Collette added a comment - - edited

        The overlay has width and height of zero, and the popup is mis-positioned, so likely there is a problem with getting the sizing of the panelGroup that they're being positioned over. Investigating further...
        The panelGroup span that everything is being positioned on has offsetHeight: 0, offsetLeft: 8, offsetTop: 670, offsetWidth: 0. Also, clientHeight: 0, clientLeft: 0, clientTop: 0, clientWidth: 0. So no wonder it's not providing sizing info. And this isn't accessed on page load, it's much later, so it's not an issue of waiting for the page to complete loading. getWidth(), getHeight() and getDimensions().width/height are all zero. The style inspector says that the width and height are "auto".

        Show
        Mark Collette added a comment - - edited The overlay has width and height of zero, and the popup is mis-positioned, so likely there is a problem with getting the sizing of the panelGroup that they're being positioned over. Investigating further... The panelGroup span that everything is being positioned on has offsetHeight: 0, offsetLeft: 8, offsetTop: 670, offsetWidth: 0. Also, clientHeight: 0, clientLeft: 0, clientTop: 0, clientWidth: 0. So no wonder it's not providing sizing info. And this isn't accessed on page load, it's much later, so it's not an issue of waiting for the page to complete loading. getWidth(), getHeight() and getDimensions().width/height are all zero. The style inspector says that the width and height are "auto".
        Hide
        Mark Collette added a comment -

        The panelGroup was being rendered as a span, which in WebKit was not reflecting the width and height of the dataTable div within it. Setting layout="block" on the panelGroup, so it would render as a div solved this. This was a QA test app change, and not a component change.

        icefaces3 trunk
        Subversion 33187

        Show
        Mark Collette added a comment - The panelGroup was being rendered as a span, which in WebKit was not reflecting the width and height of the dataTable div within it. Setting layout="block" on the panelGroup, so it would render as a div solved this. This was a QA test app change, and not a component change. icefaces3 trunk Subversion 33187

          People

          • Assignee:
            Mark Collette
            Reporter:
            Mark Collette
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: