ICEfaces
  1. ICEfaces
  2. ICE-3003

PanelDivider 2nd pane does not cover entire space

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.7
    • Fix Version/s: 1.7.1
    • Component/s: ICE-Components
    • Labels:
      None
    • Environment:
      n/a

      Description

      2nd pane in panelDivider only covers about 97% of available orientation space. The 1% taken off of each side becomes apparent when used with larger widths.
      1. screenshot-1.jpg
        67 kB
      2. screenshot-2.jpg
        180 kB
      3. screenshot-3.jpg
        171 kB
      4. screenshot-4.jpg
        179 kB
      5. screenshot-5.jpg
        174 kB
      6. screenshot-6.jpg
        172 kB

        Issue Links

          Activity

          Hide
          Ken Fyten added a comment -

          This fix causes a regression for ICE-2821 which needs to be resolved.

          Show
          Ken Fyten added a comment - This fix causes a regression for ICE-2821 which needs to be resolved.
          Hide
          yip.ng added a comment -

          ICE-2822 was really not a duplicate of ICE-2821, so it has re-surfaced as this case (ICE-3003). In fact, this problem was caused by the fix for ICE-2821. There was always a 2 or 3 % gap created on the right or bottom pane. I have tried re-calculating the percentages to be more accurate, but since we can't use exact no. of pixels, there may still be a one or two pixels difference. This difference causes the gap to still appear (one of two pixels too few) or worse, it causes the right pane to wrap around (one or two pixels too many).

          The problem is compounded by window resizing. The window resizing event is not being handled now. So on window resizing, the browser still relies on the original percentage values to resize the panels, and it seems the pixel difference will just increase, making the gap bigger or the wrapping occurring more often.

          Show
          yip.ng added a comment - ICE-2822 was really not a duplicate of ICE-2821 , so it has re-surfaced as this case ( ICE-3003 ). In fact, this problem was caused by the fix for ICE-2821 . There was always a 2 or 3 % gap created on the right or bottom pane. I have tried re-calculating the percentages to be more accurate, but since we can't use exact no. of pixels, there may still be a one or two pixels difference. This difference causes the gap to still appear (one of two pixels too few) or worse, it causes the right pane to wrap around (one or two pixels too many). The problem is compounded by window resizing. The window resizing event is not being handled now. So on window resizing, the browser still relies on the original percentage values to resize the panels, and it seems the pixel difference will just increase, making the gap bigger or the wrapping occurring more often.
          Hide
          yip.ng added a comment -

          Implemented fix that should solve issues in all the 3 cases ICE-2821, ICE-2822 and ICE-3003.

          The dimension of the 1st pane is specified as a %, while the dimension of the 2nd pane is specified as a dynamically calculated no. of pixels. The calculation occurs in these events:

          • component load
          • divider drag and drop
          • window resize

          Since there is no way to determine the exact no. of pixels in the padding, scrollbar, border, margin and margin collapsing, we have to make certain assumptions:

          • no padding in parent container div (not the one corresponding to the <panelDivider> tag, but the one created internally below that)
          • no margin in 1st pane and divider
          • no padding, border or margin in 2nd pane
            However, all the spacing and bordering can be simulated using divs containing the component or nested inside the panes.

          Note that offsetWidth includes the scrollbar width if a scrollbar is present, therefore (offsetWidth - clientWidth) doesn't always give you the border width.

          Firefox sometimes wraps the right pane around even though the pane should fit exactly in the container, therefore we have to leave a one pixel gap on the right. (Couldn't find a way to fix these after many tries. IE works fine in the many tests done so far.)

          There may be more than one divider panel on the same page, therefore on loading we need to remember not just one, but all of them for the window resize event handler.

          Show
          yip.ng added a comment - Implemented fix that should solve issues in all the 3 cases ICE-2821 , ICE-2822 and ICE-3003 . The dimension of the 1st pane is specified as a %, while the dimension of the 2nd pane is specified as a dynamically calculated no. of pixels. The calculation occurs in these events: component load divider drag and drop window resize Since there is no way to determine the exact no. of pixels in the padding, scrollbar, border, margin and margin collapsing, we have to make certain assumptions: no padding in parent container div (not the one corresponding to the <panelDivider> tag, but the one created internally below that) no margin in 1st pane and divider no padding, border or margin in 2nd pane However, all the spacing and bordering can be simulated using divs containing the component or nested inside the panes. Note that offsetWidth includes the scrollbar width if a scrollbar is present, therefore (offsetWidth - clientWidth) doesn't always give you the border width. Firefox sometimes wraps the right pane around even though the pane should fit exactly in the container, therefore we have to leave a one pixel gap on the right. (Couldn't find a way to fix these after many tries. IE works fine in the many tests done so far.) There may be more than one divider panel on the same page, therefore on loading we need to remember not just one, but all of them for the window resize event handler.

            People

            • Assignee:
              Unassigned
              Reporter:
              Philip Breau
            • Votes:
              2 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: