ActivityWatch / activitywatch

The best free and open-source automated time tracker. Cross-platform, extensible, privacy-focused.
https://activitywatch.net/
Mozilla Public License 2.0
11.94k stars 545 forks source link

TypeError: e.slice().map is not a function error after updating to version 0.13 #1067

Closed Lextum closed 3 months ago

Lextum commented 4 months ago

TypeError: e.slice().map is not a function. See dev console (F12) and/or server logs for more info.

image image

Opening the WebUI and everything is fine.

To Reproduce

Updating

While updating I found that you provide a deb package. I used the generic Linux zip file and started the binary from their.

I installed the deb file and started the application new from the /opt/activitywatch/aw-qt instead of $HOME/.local/bin/activitywatch/aw-qt

Expected behavior

Documentation

I added some screenshots above, I hope this is fine.

Additional context

Maybe another bug or mistake I made, but I enable since the update and/or enable the rust server my categorization is gone. I don't think this i related to the firefox bug.

github-actions[bot] commented 4 months ago

Hi there! As you're new to this repo, please make sure you've used an appropriate issue template and searched for duplicates (it helps us focus on actual development!). We'd also like to suggest that you read our contribution guidelines and our code of conduct. Thanks a bunch for opening your first issue! 🙏

avi-cenna commented 4 months ago

I am getting the same issue in Chrome after upgrading to v0.13. The issue pops up both with aw-server and aw-server-rust. However, in the rust version I can at least see something in the Timeline. Here is a screenshot of the Dev Tools panel showing the error.

Screenshot 2024-06-04 at 5 27 46 PM

bbrendon commented 4 months ago

Doesn't work in Brave on macOS either.

TypeError: e.slice(...).map is not a function. See dev console (F12) and/or server logs for more info.

bbrendon commented 4 months ago

[!WARNING] Important to note is that "Clearing cookies" also clears your categorization settings.

Clearing your cookies for localhost seems to fix this.

BelKed commented 3 months ago

I would assume that it's a problem with the migration to the server-side settings

avi-cenna commented 3 months ago

I confirm that clearing cookies resolved the issue. FWIW, here are the instructions to clear cookies for a single website in Chrome.

Screenshot 2024-06-05 at 10 53 02 AM

ErikBjare commented 3 months ago

Seems the issue is here: https://github.com/ActivityWatch/aw-webui/blob/05c25c98b172fcb72e2ae7cbf40be6bc77526c65/src/util/classes.ts#L109

The exact line and surrounding chunk hasn't changed in 3+ years, so it's probably an issue where classes is null/undefined for some reason. I can't really figure out why that might be, though.

Clearly something went wrong in the migration to server-side settings. I'd love to figure this out ASAP so I can ship a new patch release soon!

avi-cenna commented 3 months ago

It seems like my categories were wiped out after I cleared the cookies. Not a big deal though because my rules weren't that sophisticated anyway.

I'm not sure what could be causing the issue with classes, but I had an idea that might mitigate the issues with the migration. You can create a function that dumps the client-side settings into some kind of a cache folder managed by ActivityWatch. Then once the patch is out, the patch can read from this temporary cache file. This would allow people to clear their cookies even if it temporarily wipes out their settings. And then there's still a way to migrate them into the server-side settings.

diegonz commented 3 months ago

Yo can save you rules before clean your cookies. Go to:

  1. Developer tools (F12)
  2. Application tab
  3. Storage
  4. Local Storage
  5. http://localhost:5600

image

From the bottom part of the screen where you can see the rules (sorry I've already deleted my cookies), right click, then select copy object, then use your clipboard to fill the categories array:

{
  "categories": [
    {
      "name": [
        "Work"
      ],
      "rule": {
        "type": "regex",
        "regex": "Google Docs|libreoffice|ReText"
      },
      "data": {
        "color": "#0F0"
      },
      "id": 0
    },
    {
      "name": [
        "Work",
        "Programming"
      ],
      "rule": {
        "type": "regex",
        "regex": "GitHub|Stack Overflow|BitBucket|Gitlab|vim|Spyder|kate|Ghidra|Scite"
      },
      "id": 1
    }
  ]
}

Hope it helps someone that has lost access to settings page due to vue errors as it happened to me.

ErikBjare commented 3 months ago

I really wonder how many users will face this issue when upgrading...

@avi-cenna I edited in a warning in https://github.com/ActivityWatch/activitywatch/issues/1067#issuecomment-2148581034 so people will hopefully realize. Any proper solution would include correctly parsing the localStorage settings and migrating them to the server without any action by the user.

I realized the "e.slice().map is not a function" indicates that type of e has a slice() but not a map() on the resulting type. This probably means that e is a string and not an array as it should be, which indicates that localStorage.categories might not be parsed into JSON.


Analysis:

The issue was probably introduced in https://github.com/ActivityWatch/aw-webui/commit/1131f9b59b9291d6f6abe1d51b16a157adcdb815

When parsing we assume settings keys with a Data suffix are JSON-serialized: https://github.com/ActivityWatch/aw-webui/blame/05c25c98b172fcb72e2ae7cbf40be6bc77526c65/src/stores/settings.ts#L131-L132

But when writing we serialize all objects as JSON, so this may have been a bad assumption: https://github.com/ActivityWatch/aw-webui/blame/05c25c98b172fcb72e2ae7cbf40be6bc77526c65/src/stores/settings.ts#L183

This worked before the commit, since classes wasn't read from localStorage in the settings.ts pinia store before (fixed in https://github.com/ActivityWatch/aw-webui/pull/572).

Lextum commented 3 months ago

Thanks for the fast response and analyze. It didn't even think to check the local storage.

I was able to restore my categories and the problem with manually exporting the categories from local storage and reimported via get UI. Which likes it is working so far.

I adapted the export to be similar to the JSON generated by the export function. { "categories": [ Export from local storage] }

For me the problem is fixed. @ErikBjare should I close this issue or would like to keep it open for other users?

ErikBjare commented 3 months ago

Lets keep the issue open until I've had time to merge a fix.

avi-cenna commented 3 months ago

@ErikBjare just wanted to say thanks for developing this application. In recent weeks, I've been experimenting with several time-tracking services, such as RescueTime and ManicTime, and I have found ActivityWatch to be both the most user-friendly and the most powerful, due to the RegEx pattern matching.

ErikBjare commented 3 months ago

I think I have a fix in https://github.com/ActivityWatch/aw-webui/pull/583, but I would appreciate a review/test from someone.

BelKed commented 3 months ago

Manually verified, everything works perfectly :) https://github.com/ActivityWatch/aw-webui/pull/583#pullrequestreview-2107924431