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

    Canvas.getTop method for the rollout canvases number precision issue

    What UI interaction you are trying to achieve, from the end user's perspective.

    I have a list grid which displays the rollover canvas when the user rolls the mouse over the list. There is a bug which does not allow it for larger lists. For cases where the total height of the list grid in pixels exceeds 7 digits (greater than 999999) because of a high record count (average record height * total number of records), there are a couple of symptoms:

    - the roll over canvas does not appear on the list
    - the scroll bar moves all the way up

    The reason for that is because the roll over canvas' `top` attribute gets set to a number very close to zero (between 1 and 9 to be precise) and so the scrollHeight of the entire html element is calculated to be extremely high (therefore the scroll bar thinks the list is much greater and jumps up).


    When a CSS parameters is set (in this case top indicating the position of the rollOverCanvas which contains the action icons), it converts numbers that are large to exponent-based notation.

    As an example, at one point in the code I saw the following values (notice the difference of the top value):

    this._styleHandle.cssText: position: absolute; left: 528px; top: 1.25974e+07px; width: 168px; 12597262px
    Notice how the call to cssText converts top to exponent based values and only preserves 6 digits.

    In the list grid with 100,000 records. Record height (smart client: getAvgRowHeight()) is equal to 42px. That means, the canvas height is 4,200,000 which is beyond the 6 digit prevision limit.

    It appears, there is a bug inside smart client inside of Canvas.getTop() method which is used to decide how far from the top the rollout canvas should be displayed.

    ISC_Core.js, Canvas:

    getTop : function () {
        var handle = this.getStyleHandle();
        if (handle == null) return;
        var top = (isc.Browser.isIE ? handle.pixelTop : parseInt(;
        return top;
    Notice the call to parseInt right on the styles top value.
    Essentially, running parseInt(1.25973e+07px) would return 1 (everything after decimal point is ignored!).
    Correct way is to run parseFloat("1.25973e+07px) which would return 12597300.

    As a result, rollout canvas disappears from the screen when user scrolls beyond the height of 7 digits (1000000) which, our case is around 23 thousdand'th record on the list and the scroll bar becomes confused because it now things the scrollHeight of the list body html element is huge (the rollout action canvas is way above where the user is viewing the page).

    As a side note, smartclient makes a note in the code inside ISC_Grids.js - getTableHTML when the total height of list goes beyond 10000000 (8 digits) but this issue actually occurs when the user crosses 7 digits.

      if (totalHeight > 10000000) {
            this.logWarn("This grid is showing " + (rangeEnd - rangeStart).toLocalizedString()
                + " rows. Due to native rendering limitations, grids with this many rows"
                + " may not appear correctly on all browsers. Consider filtering the data"
                + " displayed to the user to reduce the total number of rows displayed at a time."
                + " This will improve usability as well as avoiding unpredictable behavior.");

    What you expected to happen

    I expect that the rollover canvas displays on the focused record (the record on which the mouse is hovering over) as it does correctly when the list is smaller.

    I confirmed that overriding getTop method to do parseFloat fixe the issue.

    Browser(s) and platform(s) where you see the problem

    Problem confirmed on chrome and firefox.

    SmartClient Version: v9.1p_2017-05-26/Pro Development Only (built 2017-05-26)
    Last edited by shresthg_des; 6 Nov 2017, 07:32. Reason: corrected typos

    The problem with Chrome that you point out has already been fixed in SC 10.1p and newer releases - you should really update to a newer release such as SC 11.1p in order to avoid wasting time fighting issues like these. However, we have ported back the fix now to SC 9.1p - that will be in the nightly builds dated 2017-11-10 and beyond.

    We looked but did not see any similar issue with Firefox - we checked both Firefox 52ESR and Firefox 56. If you want that pursued any further, you'll need to give us the exact version of Firefox you're using and repro code for it.