Announcement

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

  • Isomorphic
    replied
    This is hard to get to as we basically have to "steal" time since we show you as having neither licenses nor support.

    If you'd like to speed up resolution, please either become a customer, or at the least, provide a test case where we can see this actually happening, one that works on a recent version (instead of something 4 years old!).

    Internal details may be fun to gather but don't really help with resolution.

    Leave a comment:


  • pwill
    replied
    Hello Isomorphic Team,

    may I bring your attention again to this thread? Please have a look at my last two postings.

    Best regards!

    Leave a comment:


  • pwill
    replied
    Further observation shows that both isc.Browser.isChrome and isc.Browser.isSafari are true for us with Chrome 93.

    Setting isc.Browser.isSafari to false through the developer console fixes the issue of the wrong row getting selected, but it results in visual artifacts (columns are incorrectly rendered).

    In addition isc.Browser.isSafari being true leads to the following focus() call being triggered with Chrome in doHandleMouseDown (EventHandler.js:1960)
    Code:
    } else if (isc.Browser.isMoz || isc.Browser.isSafari) {
                target.focus("focus on mousedown");
    Using a workaround to prevent this call on the ListGrid object for Chrome seems to fix the issue. Further tests on our side pending.

    Leave a comment:


  • pwill
    replied
    Originally posted by Isomorphic View Post
    So to confirm, when you click in the target grid, the grid as a whole is moved, and then row that ends up selected is the row that is now under the mouse
    If breakpoints are enabled for the JavaScript functions mentioned above:
    • yes that's the behaviour, i.e. as described above under 1., 2., 3.

    If no breakpoints are enabled in the browser as a normal end user would have it:
    • in this case the grid is not moved, i.e. no scrolling is visible.
    • Still the wrong row gets selected. We assume the native scrolling happens too and then the "Reset native scroll-on-focus" of SmartGWT (Canvas.js:18173) logic gets triggered.
    • But from the code it looks like it's happening after the row selection. Shouldn't it maybe performed in advance of handling the mouse down event?

    Originally posted by Isomorphic View Post
    If that's intractable for some reason, we can give some other approaches.
    Yes, please elaborate. Reworking the layout would only be a secondary solution if at all possible in certain cases.


    Leave a comment:


  • Isomorphic
    replied
    So to confirm, when you click in the target grid, the grid as a whole is moved, and then row that ends up selected is the row that is now under the mouse?

    If so, what you're seeing is a native browser behavior where whatever is focused is moved into view.

    For end user, this is a jarring thing to happen, and the browser doesn't really let us prevent it because it's there for accessibility reasons. So the best thing for end users would be: size the grid and surrounding components so it does not end up partially out of view. This may involve using a SectionStack or similar container where you were previously just throwing several widgets into a scrolling container.

    If that's intractable for some reason, we can give some other approaches.

    Leave a comment:


  • When clicking on a certain row for the first time, a different row gets selected

    Hello Isomorphic Team,

    We are experiencing an issue when selecting rows in a ListGrid via mouse click:
    When clicking on a certain row for the first time, a different row gets selected.
    This occurs
    • with Chrome and Edge (Chromium) but not with Firefox.
    • when the ListGrid is partially not visible at the bottom i.e. it is partially scolled out of view in its parent layout. If the ListGrid is scrolled into view and completely visible the issue does not occur.

    We tried to follow the selection logic and documented the following behaviour:
    • 1. List is partially not visible at the bottom. First row is clicked.
      • element.getBoundingClientRect() for gridBody returns top = 765 (Breakpoint: Element.js:1421 getBoundingClientRect)
      • this.getOffsetY() for gridBody returns y = 97 (Breakpoint: GridRenderer.js:6464 getEventRow)
      • 4th row gets selected and parent layout is scrolled down slightly.
    • 2. First row is clicked again
      • element.getBoundingClientRect() for gridBody returns top = 765
      • this.getOffsetY() for gridBody returns y = 34
      • 1st row gets selected
    • 3. Scrolling the parent layout back up. First row is clicked.
      • element.getBoundingClientRect() for gridBody returns top = 830
      • this.getOffsetY() for gridBody returns y = 32
      • 1st row remains selected

    Note: When breakpoints are disabled the slight scrolling mentioned above does not happen. It seems the "Reset native scroll-on-focus" (Canvas.js:18173) does not get triggered when breakpoints are enabled.
    Yet the issue still occurs. When the first row is clicked the first time, a wrong row gets selected.

    Maybe the native scroll from Chrome is not properly taken into account when calculating the OffsetY?

    SmartGWT Version 6.1p-2017-09-27
    SmartClient Version v11.1p_2017-09-27

    Best regards!
Working...
X