Tabulator: tabEndNewRow lost data & doesn't focus using Firefox in classic render mode

[Jojoshua]

Describe the bug
When using the tabEndNewRow feature, tabbing at the end of the last cell is supposed to insert a new row and focus the 1st cell of the 1st column. This works in Chrome and Edge but not Firefox.

Tabulator Info
4.4.3

Working Example
https://jsfiddle.net/jojoshua/9cy310az/1/

To Reproduce

1. Click the first cell and then hit tab twice.

Expected behavior
The first cell of the new row is focused.

[olifolkerd]

Hey @Jojoshua

Thanks for the info. To be more specific it dosnt work correctly in classic render mode, when using the virtual DOM it works correctly.

I will make sure there is a fix for this in the next release.

Cheers

Oli :)

[Jojoshua]

Hey @olifolkerd, also wanted to specifically mention the data in the 2nd cell was wiped out on the tab as well. Thanks!

[olifolkerd]

Hey @Jojoshua

Looking into this further it appears to be an issue with the order that blur events are being triggered in firefox, it will take me a while to dig into this so i dont think i will have a fix in for the 4.5 release but i will get something in one of the next patch releases.

Cheres

Oli :)

[Jojoshua]

Hi @olifolkerd thanks for looking into this. Definitely looking forward to this fix.

BTW I started updating the typescript definitions for 4.5. You can check out the changes here https://github.com/DefinitelyTyped/DefinitelyTyped/pull/40620/files

[jharri43]

I also need this fixed if at all possible in the next release.

[Jojoshua]

This is a great feature and it's a shame it can't be used with Firefox yet. Thanks for keeping this on the fix list @olifolkerd

[olifolkerd]

Sorry for my last response there chaps, it was needlessly acerbic.

All im asking for is a bit of patience from people all i seem to get these days is people demanding again and again for stuff. (@Jojoshua you are being amazing, and i love the work you are putting into the type script typings)

There is only one of me and people are being rude and demanding and i do all this for free and im just starting to get tired of some peoples attitude. some of these things are so trivial that people could take 10 mins out of their day to submit a pull request but it almost never happens.

Ive had a really rough year with serious illness in the family and my father passed away a few weeks ago and all im doing is trying to do is hang in there at the moment. but from the approach of a lot of people you would think that im paid for this and have a full time staff backing me up. all im asking for is a bit of support from the community when i really really need it.

Sorry for the rant (this wasnt aimed at you @Jojoshua), i just needed to put it somewhere.

Cheers

Oli :)

[Jojoshua]

No problem @olifolkerd , sometimes you just gotta get it out to feel better. I totally understand where you are coming from. Running a project like this is surely taxing and no wonder there is so much burnout on many open source projects. Please take the time you need and come through this rough season stronger than before.

[david-simoson]

I would like to see this issue fixed as well if possible.

[JamesMotown]

Just curious if this is planned for 4.6? We've found tabEndNewRow does not work in all browsers consistently.

[olifolkerd]

Hey All,

I have pushed a fix for this to the 4.6 branch, which will be released later this weekend.

Cheers

Oli :)

[Jojoshua]

Hi Oli,

I am still experiencing this issue even using 4.6.2. https://jsfiddle.net/jojoshua/vjnkyma0/4/ shows the same example using the new version.

With Firefox, click inside the first cell, then keep tabbing through. You will eventually get the cursor to loose focus and then switch to the 2nd cell of 2nd column. It repeats this cycle for each row added.

Josh

[olifolkerd]

Hey @Jojoshua

Im afraid i cant replicate that, that fiddle works fine on firefox for me, maybe something is cached on your machine?

On a side note, there is no need for the jQuery(function($) { in your fiddle, the JS in there will be executed on ready anyway. I only mention it because it makes for a clearer minimal test case.

Cheers

Oli :)

[olifolkerd]

Hey @Jojoshua

I think i have managed to replicate what you are talking about, but as far as i can tell it only happens if you are really hammering the tab key. is that what you are experiencing?

Cheers

Oli :)

[olifolkerd]

On further investigation i can only seem to replicate this in your fiddle, when i copy your code into a blank html page the bug is not present and everything works as expected

[Jojoshua]

Yes it does seem related to timing a bit. I am also noticing that if I type in data into the fields and even slowly tab, it does not focus to the next row when I get to the 3rd row. Are you able to reproduce that?

I type a (tab) b(tab) c(tab) d(tab) then the next cell is not focused.

[Jojoshua]

Ok I still think it is related to the original issue somehow. Typically if you want to tab out of the last cell it is a fast operation so then you will start immediately typing to the next cell. Is there a settimeout somewhere?

[olifolkerd]

@Jojoshua I cant seem to replicate you a tab, b tab approach.

But looking into this further i think i can offer some explanation into what is going on here.

The reason the issue exists in the first place is due to a couple of quirks with Firefox. the first is that the browser calls some of its event handlers in a different order from other bowers. The second is that it seems to takes more time that other browsers for firefox to draw a row. the combination of these two means that in firefox it attempts to focus on the first cell in the new row before it is ready.

To address this some manual event triggering was added to ensure that events happen in the correct order and a small timeout was added to allow Firefox to catch-up before assigning focus. which seems to resolve the issue in all of my test cases, i can only see the issue appearing in your js fiddle, if i put the code in boilerplate HTML it works fine for me.

The latest problem is due to hammering of the tab key, or holding it down, causing tab events to occur faster than the row generation, causing the focus to be lost and thus restart at the top of the table. But it dosnt appear to be a problem on my browser when i take the code out of the fiddle, which suggests that the fiddle is adding additional processing overhead that is slowing things down.

I am willing to put in one more tweak to attempt to address this, but i need to be honest with you, this is a small additional feature which is only used on a small fraction of tables that is taking up a disproportionate amount of time to address an edge case usage scenario on a browser with a very small market share (and a significant set of issues with its event dispatch system), when i have other more pressing updates that are needed to Tabulator. Realistically i cannot continue to put time into this. After the 4.7 release if you are still experiencing issues with this feature then i would be happy to accept a PR form the community to resolve this but i will not be looking to peruse it any further myself.

Cheers

Oli :)

[Jojoshua]

Hi @olifolkerd thanks for looking into this again. I appreciate you wanting Tabulator to work consistently across all supported browsers and well tested against production sites.

I believe that fixing an underlying issue could improve the virtual dom rendering which affects many more scenarios. Upon some further testing of my own it appears that the virtualDom rendering is part of the issue. When I turn off virtualDom, the tabbing to new row is lightning fast and always accurate in all supported browsers.

Please try this minor adjustment https://jsfiddle.net/jojoshua/qkzbL9hj/1/

[olifolkerd]

That isnt an underlying issue as such, it is more that as of version 4.6 for your particular usage case it is advisable to turn off the virtual DOM because you are building a list that has no confined height.

As of version 4.6 the virtual DOM is enabled by default even without a height because users wanted to have it so that a table would be able to resize up till it hit the max height and then scroll, in order for this to happen the virtual DOM had to be enabled in the first place.

But this does mean that for continuously rendering tables such as your it is inefficient because it will redraw all the rows of the table when changes are made, because this is usually a subset of the view port but in your case it is all rows.

So for your usage case turning off the virtual DOM may be the correct course of action.

I have updated the release notes, upgrade guide and documentation for 4.6 to make this clearer

As i have stated in previous answers to your questions, Tabulator has two modes of operation, virtual and classic, they both have the benefits and downsides depending on use case and the choice of which one to use is down to you. There will never be a situation where they both do everything equally well as they are fundamentally different ways of building a table. The vast majority of tabulator users set heights on their tables and the Virtual DOM is used in the majority of cases as it is far more efficient and allows for much more functionality.

The classic mode is a legacy system from before the virtual DOM and can be used to fit usage cases like yours, but it comes with a cost, it is generally less efficient when dealing with large data and is much harder to manipulate so it has a poorer user experience due to the fundamental challenges of working with that many objects in the DOM simultaneously.

I am sorry that in this case Tabulator does not directly meet the needs of your usage case, as stated above If you feel there are areas that need altering to meet your needs then i would welcome a pull request with a proposed solution.

Cheers

Oli :)