Your Setup:
- Seatable Enterprise 6.0.10 self-hosted
Describe the Problem/Error/Question:
Sorry, no way to reproduce - it seems to be highly view / data / base / search term specific.
This is what happens: In a view with about 10 visible and another 100 hidden columns, with a simple (2 criteria, no group) filter and one sort, the full text search works in general. It normally finds names (“First Last”) that are in any of 5 columns that contain names either by link, link formula or as a collaborator column.
However, with one name (until now), we can reproduce the following in our data, but nowhere else. Let’s assume that the Name is “Michael Schulz“ (which it isn’t), and there are two other Michaels in the base and visible in the view. Our Michael’s Name is visible in 4 cells altogether, in 1 single rows.
While we type “M-i-c-h-a-e-l S-c-h“ in the top right search field, the search works. When we type another “u“, the screen goes blank. We don’t click on cells, don’t tab, don’t jump to the next occurence … just typing into the search box crashes the screen. Chrome, Firefox and Brave browsers.
Interesting observation: There is a “Michael Schulz“ and a “Michael Stark“ in the visible data. Right up to typing “Michael Sch“, the other Michael is also found (10 hits, 4/6 each in 2 rows). The crash seems to occur exactly at the moment when “Michael Stark“ isn’t a metach any more, because we just typed “Michael Schu“ in the search field.
Error Messages:
I can’t create an artificial use case to reproduce this, but I can give you a lot of interesting error messages. Maybe you can reverse-engineer your way to the error. The Browser console crashes like this:
commons.460958f3.js:2 Uncaught TypeError: Cannot destructure property 'column' of 'l' as it is undefined.
at xe.scrollToCurrentSelectedCell (viewDataGrid.dfb59000.js:2:2268446)
at push.41606.constructor.searchCells (viewDataGrid.dfb59000.js:2:2208311)
at ne.<anonymous> (viewDataGrid.dfb59000.js:2:509132)
at Vi (commons.460958f3.js:2:4264081)
at El (commons.460958f3.js:2:4306240)
at vl (commons.460958f3.js:2:4305808)
at vl (commons.460958f3.js:2:4305706)
at yl (commons.460958f3.js:2:4305344)
at commons.460958f3.js:2:4317181
at _u (commons.460958f3.js:2:4317696)
scrollToCurrentSelectedCell @ viewDataGrid.dfb59000.js:2
push.41606.constructor.searchCells @ viewDataGrid.dfb59000.js:2
(anonymous) @ viewDataGrid.dfb59000.js:2
Vi @ commons.460958f3.js:2
El @ commons.460958f3.js:2
vl @ commons.460958f3.js:2
vl @ commons.460958f3.js:2
yl @ commons.460958f3.js:2
(anonymous) @ commons.460958f3.js:2
_u @ commons.460958f3.js:2
ou @ commons.460958f3.js:2
b @ commons.460958f3.js:2
I @ commons.460958f3.js:2
Upon further investigation, I figured out that this line in viewDataGrid.js triggers the crash in the call of scrollToCurrentSelectedCell
0 !== p.matchedCells.length && this.scrollToCurrentSelectedCell(p, p.currentSelectIndex)
When looking at p at the time of the crash, it contains:
p: {…}
currentSelectIndex: 4
matchedCells: (4) […]
0: {…}
column: "J5UJ"
groupRowIndex: -1
row: "fpeRw9FGSFmIOxlv67Qiig"
rowIdx: 50
<prototype>: {…}
1: {…}
column: "jHGt"
groupRowIndex: -1
row: "fpeRw9FGSFmIOxlv67Qiig"
rowIdx: 50
<prototype>: {…}
2: {…}
column: "rth3"
groupRowIndex: -1
row: "fpeRw9FGSFmIOxlv67Qiig"
rowIdx: 50
<prototype>: {…}
3: {…}
column: "o49Z"
groupRowIndex: -1
row: "fpeRw9FGSFmIOxlv67Qiig"
rowIdx: 50
<prototype>: {…}
length: 4
<prototype>: []
matchedRows: {…}
fpeRw9FGSFmIOxlv67Qiig: (36) […]
0: "J5UJ"
1: "J5UJ"
2: "J5UJ"
3: "jHGt"
4: "J5UJ"
5: "jHGt"
6: "J5UJ"
7: "jHGt"
8: "rth3"
9: "J5UJ"
10: "jHGt"
11: "rth3"
12: "J5UJ"
13: "jHGt"
14: "rth3"
15: "o49Z"
16: "J5UJ"
17: "jHGt"
18: "rth3"
19: "o49Z"
20: "J5UJ"
21: "jHGt"
22: "rth3"
23: "o49Z"
24: "J5UJ"
25: "jHGt"
26: "rth3"
27: "o49Z"
28: "J5UJ"
29: "jHGt"
30: "rth3"
31: "o49Z"
32: "J5UJ"
33: "jHGt"
34: "rth3"
35: "o49Z"
length: 36
<prototype>: []
<prototype>: {…}
<prototype>: {…}
The only pattern I could find: On the crash, p.currentSelectIndex was 4, while at any other occasion, it was 0. I don’t know what the field does or where it comes from, but I strongly suspect that it somehow stores the position of the currently selected cell within the list of result cells.
Point in case #1
I suspect that a state can occur when that position is equal or larger than the number of cells found. I my case, Position 4 (or 5, zero based) in a 4-cell-array.
Point in case #2: Patching the line like this to a constant below 4 avoids crashing the browser in my test case:
0 !== p.matchedCells.length && this.scrollToCurrentSelectedCell(p, 3)
