github-starred/actual
2
0
Fork 0
mirror of https://github.com/actualbudget/actual.git synced 2026-05-05 22:52:20 -05:00
Code Issues 1.5k Packages Projects Releases 54 Wiki Activity

[GH-ISSUE #1502] [Bug]: Rules only partially loaded #7498

New Issue
Closed
opened 2026-04-10 17:21:39 -05:00 by GiteaMirror · 6 comments
GiteaMirror commented 2026-04-10 17:21:39 -05:00
Owner
Copy Link

Originally created by @willoma on GitHub (Aug 10, 2023).
Original GitHub issue: https://github.com/actualbudget/actual/issues/1502

Originally assigned to: @MatissJanis on GitHub.

Verified issue does not already exist?

  • I have searched and found no existing issue

What happened?

When accessing the "Rules" page, I only get part of them.

Until a few days ago (probably until upgrade to v23.8.0), I could scroll to the bottom of the page and other rules would be loaded.
Now, when scrolling to the bottom of the page, nothing happens.

Could it be related to #1342 ?

Moreover, filtering on rules only work on rules that have been loaded, therefore I could only filter on a subset of the rules I have.

When creating a new rule (after clicking on "Save"), all rules are loaded, filtering works as expected, etc.

What error did you receive?

No error

Where are you hosting Actual?

Docker

What browsers are you seeing the problem on?

Firefox

Operating System

Linux

Originally created by @willoma on GitHub (Aug 10, 2023). Original GitHub issue: https://github.com/actualbudget/actual/issues/1502 Originally assigned to: @MatissJanis on GitHub. ### Verified issue does not already exist? - [X] I have searched and found no existing issue ### What happened? When accessing the "Rules" page, I only get part of them. Until a few days ago (probably until upgrade to v23.8.0), I could scroll to the bottom of the page and other rules would be loaded. Now, when scrolling to the bottom of the page, nothing happens. Could it be related to #1342 ? Moreover, filtering on rules only work on rules that have been loaded, therefore I could only filter on a subset of the rules I have. When creating a new rule (after clicking on "Save"), all rules are loaded, filtering works as expected, etc. ### What error did you receive? No error ### Where are you hosting Actual? Docker ### What browsers are you seeing the problem on? Firefox ### Operating System Linux
GiteaMirror added the rulesuser interfacebug labels 2026-04-10 17:21:39 -05:00
GiteaMirror commented 2026-04-10 17:21:41 -05:00
Author
Owner
Copy Link

@MatissJanis commented on GitHub (Aug 10, 2023):

👋 Thanks for the report!

Filtering works only on the loaded rules: that's a bug for sure. We should address it.

Scrolling down does not load next page of rules: I'm unable to reproduce this on Mac + Chrome. Maybe someone else will be able to reproduce and fix. Otherwise - PRs are always welcome :)

<!-- gh-comment-id:1673544809 --> @MatissJanis commented on GitHub (Aug 10, 2023): 👋 Thanks for the report! **Filtering works only on the loaded rules**: that's a bug for sure. We should address it. **Scrolling down does not load next page of rules**: I'm unable to reproduce this on Mac + Chrome. Maybe someone else will be able to reproduce and fix. Otherwise - PRs are always welcome :)
GiteaMirror commented 2026-04-10 17:21:42 -05:00
Author
Owner
Copy Link

@willoma commented on GitHub (Aug 10, 2023):

Oh! I changed from Chrome to Firefox approximately when I installed v23.8.0.

I have just tested with Chrome again and it loads next pages.

Therefore, it looks like there are two bugs here:

1/ Filtering works only on the loaded rules
2/ Scrolling down does not load next page of rules on Firefox

<!-- gh-comment-id:1673553427 --> @willoma commented on GitHub (Aug 10, 2023): Oh! I changed from Chrome to Firefox approximately when I installed v23.8.0. I have just tested with Chrome again and it loads next pages. Therefore, it looks like there are two bugs here: 1/ Filtering works only on the loaded rules 2/ Scrolling down does not load next page of rules _on Firefox_
GiteaMirror commented 2026-04-10 17:21:43 -05:00
Author
Owner
Copy Link

@MatissJanis commented on GitHub (Aug 12, 2023):

Looked into this more, but sadly was unable to reproduce even on Firefox.

Nonetheless, my plan is to address this in two parts:

  1. separate the ManageRules mega-file with many components into smaller bits: https://github.com/actualbudget/actual/pull/1517
  2. migrate ManageRules from SimpleTable to the common Table implementation we use elsewhere - this should fix the scroll issue and also the filtering
<!-- gh-comment-id:1675929019 --> @MatissJanis commented on GitHub (Aug 12, 2023): Looked into this more, but sadly was unable to reproduce even on Firefox. Nonetheless, my plan is to address this in two parts: 1. separate the `ManageRules` mega-file with many components into smaller bits: https://github.com/actualbudget/actual/pull/1517 2. migrate `ManageRules` from `SimpleTable` to the common `Table` implementation we use elsewhere - this _should_ fix the scroll issue and also the filtering
GiteaMirror commented 2026-04-10 17:21:44 -05:00
Author
Owner
Copy Link

@jasonmichalski commented on GitHub (Jan 1, 2024):

@MatissJanis i tested https://github.com/actualbudget/actual/pull/2141 and confirmed that it fixed the filtering issue.

I was able to reproduce the scrolling issue in both firefox (linux) and chromium (windows) based browsers ... but it only seems to happen when the browser window is maximized (and make sure the developer tools aren't docked on the bottom -- needs the full height, on my monitor at least).

I added some console logging to the onScroll() function in SimpleTable like so:

  function onScroll(e) {
    if (contentHeight.current != null) {
      console.log(`${e.target.scrollTop} > ${contentHeight.current - 750}`);
      if (loadMore && e.target.scrollTop > contentHeight.current - 750) {
        loadMore();
      }
    }
  }

At the bottom of the scroll window, that value reads: 4745 > 4850, as in the scrollTop cannot get big enough to exceed the contentHeight and trigger the call to loadMore().

Not sure the best way to fix it though... it's not clear to me where that magic number 750 comes from, but increasing it to something like 1000 would do the trick (at least in my setup).

<!-- gh-comment-id:1873419685 --> @jasonmichalski commented on GitHub (Jan 1, 2024): @MatissJanis i tested https://github.com/actualbudget/actual/pull/2141 and confirmed that it fixed the filtering issue. I was able to reproduce the scrolling issue in both firefox (linux) and chromium (windows) based browsers ... but it only seems to happen when the browser window is maximized (and make sure the developer tools aren't docked on the bottom -- needs the full height, on my monitor at least). I added some console logging to the `onScroll()` function in SimpleTable like so: ```js function onScroll(e) { if (contentHeight.current != null) { console.log(`${e.target.scrollTop} > ${contentHeight.current - 750}`); if (loadMore && e.target.scrollTop > contentHeight.current - 750) { loadMore(); } } } ``` At the bottom of the scroll window, that value reads: `4745 > 4850`, as in the `scrollTop` cannot get big enough to exceed the `contentHeight` and trigger the call to `loadMore()`. Not sure the best way to fix it though... it's not clear to me where that magic number 750 comes from, but increasing it to something like 1000 would do the trick (at least in my setup).
GiteaMirror commented 2026-04-10 17:21:44 -05:00
Author
Owner
Copy Link

@twk3 commented on GitHub (Jan 3, 2024):

@MatissJanis i tested #2141 and confirmed that it fixed the filtering issue.

I was able to reproduce the scrolling issue in both firefox (linux) and chromium (windows) based browsers ... but it only seems to happen when the browser window is maximized (and make sure the developer tools aren't docked on the bottom -- needs the full height, on my monitor at least).

I added some console logging to the onScroll() function in SimpleTable like so:

  function onScroll(e) {
    if (contentHeight.current != null) {
      console.log(`${e.target.scrollTop} > ${contentHeight.current - 750}`);
      if (loadMore && e.target.scrollTop > contentHeight.current - 750) {
        loadMore();
      }
    }
  }

At the bottom of the scroll window, that value reads: 4745 > 4850, as in the scrollTop cannot get big enough to exceed the contentHeight and trigger the call to loadMore().

Not sure the best way to fix it though... it's not clear to me where that magic number 750 comes from, but increasing it to something like 1000 would do the trick (at least in my setup).

I see this same issue pretty consistently in firefox. The closest e.target.scrollTop I can get in onScroll is 751 off of the contentHeight so loadMore never fires.

<!-- gh-comment-id:1874716648 --> @twk3 commented on GitHub (Jan 3, 2024): > @MatissJanis i tested #2141 and confirmed that it fixed the filtering issue. > > I was able to reproduce the scrolling issue in both firefox (linux) and chromium (windows) based browsers ... but it only seems to happen when the browser window is maximized (and make sure the developer tools aren't docked on the bottom -- needs the full height, on my monitor at least). > > I added some console logging to the `onScroll()` function in SimpleTable like so: > > ```js > function onScroll(e) { > if (contentHeight.current != null) { > console.log(`${e.target.scrollTop} > ${contentHeight.current - 750}`); > if (loadMore && e.target.scrollTop > contentHeight.current - 750) { > loadMore(); > } > } > } > ``` > > At the bottom of the scroll window, that value reads: `4745 > 4850`, as in the `scrollTop` cannot get big enough to exceed the `contentHeight` and trigger the call to `loadMore()`. > > Not sure the best way to fix it though... it's not clear to me where that magic number 750 comes from, but increasing it to something like 1000 would do the trick (at least in my setup). I see this same issue pretty consistently in firefox. The closest e.target.scrollTop I can get in onScroll is 751 off of the contentHeight so loadMore never fires.
GiteaMirror commented 2026-04-10 17:21:45 -05:00
Author
Owner
Copy Link

@jasonmichalski commented on GitHub (Jan 3, 2024):

I didn't get a chance to try it yet, but I think that 750 might've been an attempt to compensate for the scrollHeight:

https://developer.mozilla.org/en-US/docs/Web/API/Element/scrollHeight#determine_if_an_element_has_been_totally_scrolled

Just a guess at this point, but thinking that 750 works for some displays, but not all and using scrollHeight is more universal. If no one beats me to it, I'll play around with it tomorrow and report back.

<!-- gh-comment-id:1874750916 --> @jasonmichalski commented on GitHub (Jan 3, 2024): I didn't get a chance to try it yet, but I think that 750 might've been an attempt to compensate for the `scrollHeight`: https://developer.mozilla.org/en-US/docs/Web/API/Element/scrollHeight#determine_if_an_element_has_been_totally_scrolled Just a guess at this point, but thinking that 750 works for some displays, but not all and using scrollHeight is more universal. If no one beats me to it, I'll play around with it tomorrow and report back.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
AI generated
API
bank sync
budgeting
bug
can’t replicate
dependencies
docker
documentation
electron
experimental feature
feature
feedback
goal templates
good first issue
help wanted
importers
maintenance
needs info
needs testing
needs triage
needs votes
openid
payees
pull-request
Mirrored from GitHub Pull Request
 regression
reports
responsive
rules
schedules
server
✨ merged
split transactions
tech debt
theme
transaction import
transaction reconciliation
transactions
translations
upstream
user interface
✅ approved
wontfix
No Label bug rules user interface
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/actual#7498
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?