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).
Details:
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):
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:
Notice the call to parseInt right on the style’s 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.
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)
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).
Details:
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):
Code:
this._styleHandle.cssText: “position: absolute; left: 528px; top: 1.25974e+07px; width: 168px;……” this._styleHandle.top: “12597262px”
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:
Code:
getTop : function () {
var handle = this.getStyleHandle();
if (handle == null) return this.top;
var top = (isc.Browser.isIE ? handle.pixelTop : parseInt(handle.top));
return top;
},
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.
Code:
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)
Comment