starred/floccus

Fork 0

mirror of https://github.com/floccusaddon/floccus.git synced 2026-04-25 06:06:05 +03:00

[GH-ISSUE #1997] Error: Cannot read properties of undefined (reading 'tagName') #1338

New issue

Closed

opened 2026-02-25 22:39:43 +03:00 by kerem · 8 comments

kerem commented

2026-02-25 22:39:43 +03:00

Owner

Originally created by @JeGr on GitHub (Jul 22, 2025).
Original GitHub issue: https://github.com/floccusaddon/floccus/issues/1997

Which version of floccus are you using?

5.5.6

How many bookmarks do you have, roughly?

~800

Are you using other means to sync bookmarks in parallel to floccus?

Sync method

WebDAV

Which browser are you using? In case you are using the phone App, specify the Android or iOS version and device please.

Brave 1.80.122 / Firefox 140 (all latest)

Which version of Nextcloud Bookmarks are you using? (if relevant)

Which version of Nextcloud? (if relevant)

What kind of WebDAV server are you using? (if relevant)

Caddy Addon/Module

Describe the Bug

Since 2 or 3 Minor Releases ago, the bookmark extension on Chrome/Brave as well as Firefox aren't able to access my WebDAV share anymore. If I access it with user/password via its URI on those browsers natively or try access it through other means, the file can be accessed without problem, so WebDAV access seems fine and hasn't changed. I think the last version that worked was maybe 5.5.2 or 5.5.3?
Since then it throws the error and aborts the connection.

2025-07-22T12:58:54.467Z Starting sync process for account Bookmarks Backup
2025-07-22T12:58:54.468Z onSyncStart: begin
2025-07-22T12:58:54.468Z ###server###user-floccus/bookmarks.xbel.lock
2025-07-22T12:58:54.484Z Setting lock: ###server###user-floccus/bookmarks.xbel.lock
2025-07-22T12:58:54.724Z Syncing failed with Cannot read properties of undefined (reading 'tagName')
2025-07-22T12:58:54.725Z onSyncFail
2025-07-22T12:58:54.725Z Freeing lock: ###server###user-floccus/bookmarks.xbel.lock

Expected Behavior

sync to WebDAV going through :)

To Reproduce

Default Setup for WebDAV. Worked as intended, now gives the above error.
Debug Log only lists the lines above.

Debug log provided

I have provided a debug log file

Originally created by @JeGr on GitHub (Jul 22, 2025). Original GitHub issue: https://github.com/floccusaddon/floccus/issues/1997 ### Which version of floccus are you using? 5.5.6 ### How many bookmarks do you have, roughly? ~800 ### Are you using other means to sync bookmarks in parallel to floccus? No ### Sync method WebDAV ### Which browser are you using? In case you are using the phone App, specify the Android or iOS version and device please. Brave 1.80.122 / Firefox 140 (all latest) ### Which version of Nextcloud Bookmarks are you using? (if relevant) - ### Which version of Nextcloud? (if relevant) - ### What kind of WebDAV server are you using? (if relevant) Caddy Addon/Module ### Describe the Bug Since 2 or 3 Minor Releases ago, the bookmark extension on Chrome/Brave as well as Firefox aren't able to access my WebDAV share anymore. If I access it with user/password via its URI on those browsers natively or try access it through other means, the file can be accessed without problem, so WebDAV access seems fine and hasn't changed. I think the last version that worked was maybe 5.5.2 or 5.5.3? Since then it throws the error and aborts the connection. ``` 2025-07-22T12:58:54.467Z Starting sync process for account Bookmarks Backup 2025-07-22T12:58:54.468Z onSyncStart: begin 2025-07-22T12:58:54.468Z ###server###user-floccus/bookmarks.xbel.lock 2025-07-22T12:58:54.484Z Setting lock: ###server###user-floccus/bookmarks.xbel.lock 2025-07-22T12:58:54.724Z Syncing failed with Cannot read properties of undefined (reading 'tagName') 2025-07-22T12:58:54.725Z onSyncFail 2025-07-22T12:58:54.725Z Freeing lock: ###server###user-floccus/bookmarks.xbel.lock ``` ### Expected Behavior sync to WebDAV going through :) ### To Reproduce Default Setup for WebDAV. Worked as intended, now gives the above error. Debug Log only lists the lines above. ### Debug log provided - [x] I have provided a debug log file

kerem

2026-02-25 22:39:43 +03:00

closed this issue
added the
bug

feature: webdav
labels

kerem commented

2026-02-25 22:39:44 +03:00

Author

Owner

@github-actions[bot] commented on GitHub (Jul 22, 2025):

Hello 👋

Thank you for taking the time to open this issue with floccus. I know it's frustrating when software
causes problems. You have made the right choice to come here and open an issue to make sure your problem gets looked at
and if possible solved. Let me give you a short introduction on what to expect from this issue tracker to avoid misunderstandings.
I'm Marcel. I created floccus a few years ago, and have been maintaining it since. I currently work for Nextcloud
which leaves me with less time for side projects like this one than I used to have.
I still try to answer all issues and if possible fix all bugs here, but it sometimes takes a while until I get to it.
Until then, please be patient. It helps when you stick around to answer follow up questions I may have,
as very few bugs can be fixed directly from the first bug report, without any interaction. If information is missing in your bug report
and the issue cannot be solved without it, I will have to close the issue after a while.
Note also that GitHub in general is a place where people meet to make software better together. Nobody here is under any obligation
to help you, solve your problems or deliver on any expectations or demands you may have, but if enough people come together we can
collaborate to make this software better. For everyone.
Thus, if you can, you could also have a look at other issues to see whether you can help other people with your knowledge
and experience. If you have coding experience it would also be awesome if you could step up to dive into the code and
try to fix the odd bug yourself. Everyone will be thankful for extra helping hands!
If you cannot lend a helping hand, to continue the development and maintenance of this project in a sustainable way,
I ask that you donate to the project when opening an issue (or at least once your issue is solved), if you're not a donor already.
You can find donation options at https://floccus.org/donate/. Thank you!

One last word: If you feel, at any point, like you need to vent, this is not the place for it; you can go to the Nextcloud forum,
to twitter or somewhere else. But this is a technical issue tracker, so please make sure to
focus on the tech and keep your opinions to yourself.

Thank you for reading through this primer. I look forward to working with you on this issue!
Cheers 💙

@github-actions[bot] commented on GitHub (Jul 22, 2025): Hello :wave: Thank you for taking the time to open this issue with floccus. I know it's frustrating when software causes problems. You have made the right choice to come here and open an issue to make sure your problem gets looked at and if possible solved. Let me give you a short introduction on what to expect from this issue tracker to avoid misunderstandings. I'm Marcel. I created floccus a few years ago, and have been maintaining it since. I currently work for Nextcloud which leaves me with less time for side projects like this one than I used to have. I still try to answer all issues and if possible fix all bugs here, but it sometimes takes a while until I get to it. Until then, please be patient. It helps when you stick around to answer follow up questions I may have, as very few bugs can be fixed directly from the first bug report, without any interaction. If information is missing in your bug report and the issue cannot be solved without it, I will have to close the issue after a while. Note also that GitHub in general is a place where people meet to make software better *together*. Nobody here is under any obligation to help you, solve your problems or deliver on any expectations or demands you may have, but if enough people come together we can collaborate to make this software better. For everyone. Thus, if you can, you could also have a look at other issues to see whether you can help other people with your knowledge and experience. If you have coding experience it would also be awesome if you could step up to dive into the code and try to fix the odd bug yourself. Everyone will be thankful for extra helping hands! If you cannot lend a helping hand, to continue the development and maintenance of this project in a sustainable way, I ask that you donate to the project when opening an issue (or at least once your issue is solved), if you're not a donor already. You can find donation options at <https://floccus.org/donate/>. Thank you! One last word: If you feel, at any point, like you need to vent, this is not the place for it; you can go to the Nextcloud forum, to twitter or somewhere else. But this is a technical issue tracker, so please make sure to focus on the tech and keep your opinions to yourself. Thank you for reading through this primer. I look forward to working with you on this issue! Cheers :blue_heart:

kerem commented

2026-02-25 22:39:44 +03:00

Author

Owner

@JeGr commented on GitHub (Jul 22, 2025):

If some information is missing, I have two systems that show the exact same issue to try to debug them and will gladly provide as much info and help as I can.

@JeGr commented on GitHub (Jul 22, 2025): If some information is missing, I have two systems that show the exact same issue to try to debug them and will gladly provide as much info and help as I can.

kerem commented

2026-02-25 22:39:44 +03:00

Author

Owner

@marcelklehr commented on GitHub (Jul 22, 2025):

Hey @JeGr
Thank you for taking the time to give feedback by opening this issue!
It seems like the xml parser chokes on your XBEL file.
Could you check the xbel file content and maybe run it through a validator to make sure it's valid XML? If not there might be an issue with one of your bookmarks that causes broken XML.

@marcelklehr commented on GitHub (Jul 22, 2025): Hey @JeGr Thank you for taking the time to give feedback by opening this issue! It seems like the xml parser chokes on your XBEL file. Could you check the xbel file content and maybe run it through a validator to make sure it's valid XML? If not there might be an issue with one of your bookmarks that causes broken XML.

kerem commented

2026-02-25 22:39:44 +03:00

Author

Owner

@JeGr commented on GitHub (Jul 22, 2025):

Interesting! I had a quick look and it seems at one point floccus seems to have garbled the upload (the location is upload only, no sync, no download, just store and forget to have a copy for mobile as GIT isn't working there).

The XML stops in the middle of a bookmark tag. Either a timeout or some other thing seems to have cut the upload and afterwards, floccus wouldn't touch it anymore. After deleting the error was gone and the upload is back and around a fourth the size of before. (540kb vs now 130kb). Huh. So now it's working again :)

Buuuut: shouldn't floccus just ignore the whole shebang in my setup anyways? It's configured as ONLY upload, ignore anything else and even with cache reset etc. it wouldn't even start another upload before parsing the file (thus falling flat because it had broken XML)? I think that shouldn't be the case when I do a forced upload and even have "upload anyways, ignore other browsers and stuff" chosen as an option? When you don't have to sync, why not "just upload" the new file without checking? Is it because of some delta updating algo? :)

Cheers,
\jens

@JeGr commented on GitHub (Jul 22, 2025): Interesting! I had a quick look and it seems at one point floccus seems to have garbled the upload (the location is upload only, no sync, no download, just store and forget to have a copy for mobile as GIT isn't working there). The XML stops in the middle of a bookmark tag. Either a timeout or some other thing seems to have cut the upload and afterwards, floccus wouldn't touch it anymore. After deleting the error was gone and the upload is back and around a fourth the size of before. (540kb vs now 130kb). Huh. So now it's working again :) Buuuut: shouldn't floccus just ignore the whole shebang in my setup anyways? It's configured as ONLY upload, ignore anything else and even with cache reset etc. it wouldn't even start another upload before parsing the file (thus falling flat because it had broken XML)? I think that shouldn't be the case when I do a forced upload and even have "upload anyways, ignore other browsers and stuff" chosen as an option? When you don't have to sync, why not "just upload" the new file without checking? Is it because of some delta updating algo? :) Cheers, \jens

kerem commented

2026-02-25 22:39:44 +03:00

Author

Owner

@marcelklehr commented on GitHub (Jul 23, 2025):

So now it's working again :)

Nice, I'm glad we figured it out!

When you don't have to sync, why not "just upload" the new file without checking?

Indeed, that would be an improvement. Due to the modularity of the code the webdav adapter doesn't know which sync strategy the user has selected and just stupidly does everything regardless of that. Only the sync module knows the sync strategy.

@marcelklehr commented on GitHub (Jul 23, 2025): > So now it's working again :) Nice, I'm glad we figured it out! > When you don't have to sync, why not "just upload" the new file without checking? Indeed, that would be an improvement. Due to the modularity of the code the webdav adapter doesn't know which sync strategy the user has selected and just stupidly does everything regardless of that. Only the sync module knows the sync strategy.

kerem commented

2026-02-25 22:39:44 +03:00

Author

Owner

@JeGr commented on GitHub (Jul 24, 2025):

Nice, I'm glad we figured it out!

Absolutely! Thanks for that!

Indeed, that would be an improvement. Due to the modularity of the code the webdav adapter doesn't know which sync strategy the user has selected and just stupidly does everything regardless of that. Only the sync module knows the sync strategy.

Ah that's where it comes from. Got it.

I think I also got a trace about why it happened in the first place. I sync the folder of my bookmark toolbar. In that folder I have another folder "other browsers" where I have the bookmarks currently open in other browsers (only one other at the moment). To avoid setting up multiple syncs per browser instead I configured a second job for my own browser on that machine to sync its current open bookmarks to another location (another branch in git) and a third job to pull that git back into the "other browsers/browser1" folder. The same goes for the other laptop and browser with "other browsers/browser2". That way I have only 3 jobs per client to configure instead of 1 for floccus and N-1 for all the other browser's open tabs. And as the main sync job already includes the "other browsers" folder, I won't have to sync them all but only my own to the bunch. At least that was the plan.

It seems that somehow that "push open tabs into git, pull from git into folder" got scrambled at one point as the browser1 folder "Window 0" had a HUGE number of entries that seems to have been added to over and over again instead of sync the current "Window 0". After I deleted all "Window X" entries, the push/pull jobs seem to work fine again, but now I'm thinking that perhaps they collide with the main sync job. Any thoughts about it?
Perhaps it's safer like you documented to actually to that browser tab refreshing in a separate bookmark folder that is NOT included in the main sync but separate and thus not colliding with other sync options?

That's as far as I can diagnose it currently but I'll keep an eye out. Still no chance of getting that GIT sync going on Android currently? ;)

Cheers :)

@JeGr commented on GitHub (Jul 24, 2025): > Nice, I'm glad we figured it out! Absolutely! Thanks for that! > Indeed, that would be an improvement. Due to the modularity of the code the webdav adapter doesn't know which sync strategy the user has selected and just stupidly does everything regardless of that. Only the sync module knows the sync strategy. Ah that's where it comes from. Got it. I think I also got a trace about why it happened in the first place. I sync the folder of my bookmark toolbar. In that folder I have another folder "other browsers" where I have the bookmarks currently open in other browsers (only one other at the moment). To avoid setting up multiple syncs per browser instead I configured a second job for my own browser on that machine to sync its current open bookmarks to another location (another branch in git) and a third job to pull that git back into the "other browsers/browser1" folder. The same goes for the other laptop and browser with "other browsers/browser2". That way I have only 3 jobs per client to configure instead of 1 for floccus and N-1 for all the other browser's open tabs. And as the main sync job already includes the "other browsers" folder, I won't have to sync them all but only my own to the bunch. At least that was the plan. It seems that somehow that "push open tabs into git, pull from git into folder" got scrambled at one point as the browser1 folder "Window 0" had a HUGE number of entries that seems to have been added to over and over again instead of sync the current "Window 0". After I deleted all "Window X" entries, the push/pull jobs seem to work fine again, but now I'm thinking that perhaps they collide with the main sync job. Any thoughts about it? Perhaps it's safer like you documented to actually to that browser tab refreshing in a separate bookmark folder that is NOT included in the main sync but separate and thus not colliding with other sync options? That's as far as I can diagnose it currently but I'll keep an eye out. Still no chance of getting that GIT sync going on Android currently? ;) Cheers :)

kerem commented

2026-02-25 22:39:44 +03:00

Author

Owner

@marcelklehr commented on GitHub (Jul 30, 2025):

It seems that somehow that "push open tabs into git, pull from git into folder" got scrambled at one point as the browser1 folder "Window 0" had a HUGE number of entries that seems to have been added to over and over again instead of sync the current "Window 0".

Mmh, I'm not sure what could have caused that. Syncing nested folders with different profiles should work fine.

That's as far as I can diagnose it currently but I'll keep an eye out.

Awesome, looking forward to hearing about that :)

Still no chance of getting that GIT sync going on Android currently? ;)

Sadly no :/ I keep testing it every few months, but it seems to have a low priority for the devs of the mobile framework. I might just point an AI at the problem at some point to fix it :D

@marcelklehr commented on GitHub (Jul 30, 2025): > It seems that somehow that "push open tabs into git, pull from git into folder" got scrambled at one point as the browser1 folder "Window 0" had a HUGE number of entries that seems to have been added to over and over again instead of sync the current "Window 0". Mmh, I'm not sure what could have caused that. Syncing nested folders with different profiles should work fine. > That's as far as I can diagnose it currently but I'll keep an eye out. Awesome, looking forward to hearing about that :) > Still no chance of getting that GIT sync going on Android currently? ;) Sadly no :/ I keep testing it every few months, but it seems to have a low priority for the devs of the mobile framework. I might just point an AI at the problem at some point to fix it :D

kerem commented

2026-02-25 22:39:44 +03:00

Author

Owner

@marcelklehr commented on GitHub (Aug 3, 2025):

This issue should be fixed now in the latest release. Thank you for your cooperation 💙

@marcelklehr commented on GitHub (Aug 3, 2025): This issue should be fixed now in the latest release. Thank you for your cooperation 💙

kerem referenced this issue

2026-02-25 23:31:04 +03:00

[PR #1338] [CLOSED] Bump vue-loader from 15.10.1 to 17.0.1 #1865

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/floccus#1338

No description provided.

Rows
Columns