Search filter text from one tab is getting distributed in all open checkvist windows/tabs

đź’© Bugs
1

I usually keep several checkvist tabs open with different filters on each of them e.g (due:now, priority:1 etc. etc.)

This used to work very well all this while except for recently I see that filters from one of the tabs gets applied automatically to other open tabs.
This usually happens with the most recent changed filter (e.g. if I change the filter to due:now on one of the tabs, then after a while, I see that the same filter (due:now) is applied on all the other tabs).

I remember reporting this problem earlier, and then it was fixed, but it seems to have regressed again now.

2

Hi @saurabhg9,

With the old implementation there was a problem that the filter line was remembered for too long time, and it was annoying, when you come to a list and it was filtered with text used days ago.

So now we’ve added an expiration time for this filter, one hour since page load/filter use.

Now, I’ve increased the timeout to 4 hours for a tab, please check how it works on https://beta.checkvist.com.

Regards,
KIR

3

Hi Kir,

My workflow requires keeping several checkvist tabs open in a browser set, with 4 different views i.e. priority:1, priority:2, #active and due:now

These windows are open all the time as I work through my daily activities focussing on different areas that I manage using checkvist (and it works perfectly so far)

Would the new change you mention require me to have to set them up once every 4 hours? If so, then is there a workaround to this, as it would be a bummer otherwise having to reset my views every 4 hours.

Or to put it the other way around - as long as my checkvist session is active, it would be preferable to not lose my work instance including set filters etc.

(updates after testing the new changes on the beta site) -

The issue still persists. I randomly lose my filter on a tab I am still working on and it switches to some filter I had used recently, requiring me to change it back again.

Thanks,
Saurabh

4

I also ran into this a while ago, as I usually suffer from excessive tab/window use. I did not expect this kind of interference but accepted that sometimes strange things happen.

1 Like
5

This issue unfortunately also happens when you have only 2 tabs.
After a while, the filter on both the tabs get force-synchronized, so you get to see the same view in both the tabs and have to change it back manually.

6

Hello @saurabhg9,

We’ve increased the tab timeout to 48 hours, hope this will work better for your scenario.

Kind regards,
KIR

7

Hi Kir,

Maybe, I am missing something, but shouldn’t the set filter not be over-written until browser session expiry/logout/application window close, as the behavior was before?
That would be the expected application behavior, as it is also in many other application paradigms. Right?

You mentioned about this reasoning below, but unfortunately the very same thing still holds true, but in a different context i.e. users will come to an active list they are still using and find that it no longer looks like it used 48 hours ago.

So maybe what you are trying to solve needs to be solved in some other way, as the current solution creates a similar problem the other way around?

If it is a new browser session, then filters could be reset (though that could also be argued, as you might want to support view restoration on session activation), but that would clearly not be acceptable on an existing active session.

I can imagine other scenarios as well where this would be an issue, example showing the list on a LED screen for a team with certain filters active, so they always see the view relevant for them. Having any kinds of filter time-outs will defeat those scenarios.

Sorry to pester you on this, but this one really annoys me as I can no longer trust the checkvist view on my browser and have to always double-check if the filters have changed since I last set them the way they should be.

---------- Update from 2020-04-17

Was working on a new checkvist page with no filters, but every few minutes it would automatically put the “priority:1” filter on it, requiring me to manually clear the filter out.

This happened 2-3 times in a span of 10 minutes. Likely this is not a new bug and related to the above topic itself, hence not reporting it as a new bug.

Regards,
Saurabh

8

This could have been caused by a “filter=xxx” part in URL which Checkvist adds when navigating to a list from global search results. Now, when clearing the filter, this URL part is removed (just deployed the fix). Hope this was it, otherwise don’t understand where this problem could come from :frowning:

9

Hi Kir

I think the issue still exists.

I have now tried to find an easy way to reproduce this (on the beta website)

  1. Open a new browser instance to your list and filter it with something e.g. priority:1 or due:now etc. (let’s called the filter F1)

  2. Open a new browser tab to your list and filter it with something else other than what you have filtered on the first tab (let’s called the filter F2)

  3. Try to copy link to a list item (lc shortcut) and try to open it on the third tab - it will not be able to successfully navigate to that list item, and the filter on this third tab will be randomly set to either F1 or F2 (borrowed from either of the previously open tabs).

I feel there is some deep bug related to the above discussion that is currently hampering usage of checkvist on multiple tabs, as there seems to be some cross- synchronization happening between the tabs. Some kind of race condition between session variables.

Checkvist on multiple tabs are no longer independent of each other and many areas (e.g. filters, focus/hoist etc.) are getting copied over from other tabs.

Could it be that these items (e.g. filters, focus/hoist etc.) were earlier page scoped variables and have now become session scoped thereby affecting all browser tabs having the same user session?

10

Hi Saurabh,

Checkvist always remembered the last filter chosen for a list. So the next time you open this list in a new tab in the same browser without clearing the filter - the filter was restored. With the recent updates, we reduced the timespan when this happens to one hour, previously it worked indefinitely.

At the same time, you can use different filters in already open tabs, and they were stored on per-tab basis. The time during which the filter is remembered for already open tab is currently 48 hours.

Thanks! This is clearly a bug, and as far as I can tell it is not related to recent changes. I’ve fixed this problem and deployed the fix to https://beta.checkvist.com, hope it will work correctly now. I.e. if you’re navigating to a task which is hidden by a remembered filter, the filter should now be removed.

Hope this would work better,
KIR

11

Hi Kir

Just tested this part of the issue -

It seems to now open the copied link to list (through “lc”) with the behaviour that the opened list items are not always hoisted. Earlier default behaviour was that all list items that are opened through link (lc) were hoisted.
After some more debugging, I have found that list items that have child items will be hoisted, and list items with no child items are not hoisted (the list page simply opens with all the other items, albeit the keyboard focus is on the list item)

12

Thanks for testing!

This is by design, always worked this way. What is a need to hoist an item when it does not have children? When we tried to hoist even leaf items, it was rather annoying, because one have to un-focus, almost always.

This works in all cases when navigating to a single task, not only when filter is present.

Best,

13

Hi,

A reason to hoist leaf items would be to focus on it in order to add more items.

IMHO, from a paradigm / KISS perspective, it is cognitively easier that the behavior of opening LC is uniform i.e. open the item hoisted up (irrespective of whether it has child items previously or not).

14

Correct, but in my practice, this is a minority of cases when you navigate to a task. Reading is usually a more often operation than writing.

We tried that. Did not work nicely, again, in most cases. So I don’t think we will be changing the behaviour now, sorry.

15

Hi Kir,

I think I have stumbled across a bug that is relating to the above discussion.

Steps to reproduce -

  1. Open a list in browser tab (T1) and filter it with something e.g. priority:1 or due:now etc. (F1)

  2. Open the same list in a second browser tab (T2) and filter it with something e.g. priority:1 or due:now etc. (F2)

  3. Open the same list in a third browser tab (T3) and do not filter it with anything i.e. clear of any filters.

  4. Now make edits to the list in T1 or T2 e.g. add a list item and delete it.
    Within a few seconds the filter on T3 is updated to F1 or F2 (randomly, as far as I can see)

To summarize the issue -

“In a multi-tab usage environment, a tab that does not have a filter on it will be prone to have a filter forcibly applied on it, in case any of the other filtered tabs experiences an edit. The edit has to be in form of addition or removal of a list item and not change of date or tag. Also the edit has to occur on a tab that is already filtered.”

Another possibly related issue that I observed today was that the rf shortcut which was used to refresh the list items in the page did not work in the same way as it did earlier.

Taking the above example, if we add a list item to T3 which falls in the filter criteria of F1 or F2, and then I do a rf on any of those tabs (T1 or T2), then it would not refresh the items and not show the newly added item. However if I try it again after say 5-10 seconds, it would work and show the newly added item.

16

Thanks, looks like this is a new bug I’ve introduced. Hope to fix it soon, will let you know.

1 Like
17

HI Kir,

I have observed one more behavior today, which is likely an extension of the above bug.

The behavior is that when I have hoisted a leaf-item in one of the tabs, the other tabs also got affected and they also had the hoisting done (probably some kind of synchronizing effect). This happens randomly, so hard to lay out exact steps to reproduce.

Thought it might be good to inform you about it while you are looking into the above.

Thanks
Saurabh

18

Hi @saurabhg9,

On https://beta.checkvist.com, I’ve fixed the issue when cleared filter in one tab got a filter from another tab.
Thanks for reporting it. :slight_smile:

As for the hoisting issue - if you open a new tab of a list, it would inherit the last hoisted task you used. If you change the hoist level in the tab (or clear the hoist), it should be remembered for this tab and new hoist value will be used for new opened tabs with this list.

All the best,

19

Great. Just tested it, it seems to be working well. Thank you.

1 Like