mirror of
https://github.com/floccusaddon/floccus.git
synced 2026-04-26 22:55:59 +03:00
[GH-ISSUE #1000] floccus unsupported browser message(android) #655
Labels
No labels
browser-specific
bug
correctness issues
enhancement
feature: Google Drive
feature: Linkwarden
feature: git
feature: nextcloud-bookmarks
feature: tabs
feature: webdav
help wanted
native-app
priority: high
priority: low
priority: medium
pull-request
question
question
stale
upstream
waiting for more information
wontfix
🙁 Not following issue template
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/floccus#655
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
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?
Originally created by @swestlake on GitHub (Nov 18, 2021).
Original GitHub issue: https://github.com/floccusaddon/floccus/issues/1000
Describe the bug
floccus attempts to sync(as an add-on to kiwi-browser on android), several minutes later says it cannot sync on unsupported browser.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
green check-mark for a succeeded sync
Screenshots
Desktop
(please complete the following information)
Server
Debug log
none
Additional context
no additional context available
@marcelklehr commented on GitHub (Nov 18, 2021):
Can you share a screenshot of the error, please?
@swestlake commented on GitHub (Nov 18, 2021):
the sync runs for a long time with the 908 bookmark items..
(desktop syncs occur relatively quickly, however the android setup is
much longer that it is not really practical)
eventually the message becomes something along the lines that it is not
a support browser. It said something about the browser, and iirc it said unsupported.
I will try to give a screenshot at some point later today or tomorrow.
thanks
On Nov 18 2021, at 9:02 am, Marcel Klehr @.***> wrote:
@marcelklehr commented on GitHub (Nov 18, 2021):
Also see this issue about using floccus with owncloud: https://github.com/floccusaddon/floccus/issues/841
@swestlake commented on GitHub (Nov 18, 2021):
@marcelklehr , take note the "Desktop" heading is misleading, and had to be used in order to fulfill the template requirements (for the bugreport). The bug is taking place from android kiwi+floccus extension.
The sync is 100% successful only on Desktop web-browsers (four in total are used on multiple machines).
The only sync not working is the kiwi browser on Android. No other Android browser has yet been tested, though I suppose those would be less compatible than kiwi at this currrent time according to notes on the site of the project.
the setting is set the same on all floccus instances(both desktop and android), so there's nothing differing in this... so I would not be exactly sure as to why this isn't working.
I will try to check to see if there is a lock-file getting created (the hidden files would need be enabled on the webdav server as well).
@swestlake commented on GitHub (Nov 18, 2021):
perhaps it could be valuable to troubleshoot the chrome-extension plugin, because all the settings are set the same on 5 web-browsers.
{{ 1 firefox, 1 chrome }} on one machine
{{ 1 firefox, 1 chrome }} on another machine on the same network
then
1 kiwi on Android. Doesn't pass.
I am using the official "owncloud" docker image.
Question:: your chrome-extension should work with the official owncloud docker image as well?
something doesn't seem right....
@marcelklehr commented on GitHub (Nov 18, 2021):
Without the the exact error message, I cannot do much. As far as I can remember webDAV sync with owncloud doesn't work, but of course if it works on your desktop that would indicate a different cause of your problems. When comparing browsers, also check the extension version.
@swestlake commented on GitHub (Nov 18, 2021):
I think part of the reason why webdav is not working for some users is they are using the incorrect URL.
One symptom, is the connection stays on for a very long time and nothing happens... it's like stuck in a loop. << perhaps the logic in the extension needs to be improved for this.
"As far as I can remember webDAV sync with owncloud doesn't work"
^ you must be lacking testers in this area, because afaict webdav is working very stable here...and I am glad to be giving feedback!!
https://domain.com/remote.php/dav/files/user/ << is what I use for all my configurations.
I am using Owncloud 10.5 and 10.8... << floccus works on these two versions(docker)
On my first LAN, I am using owncloud 10.8 <<< works across 2 machines -- 4 desktop Web-browsers
On my second LAN, I am using owncloud 10.5 <<< works across 2 machines. -- 2 desktop Web-browsers.
^^ The problem is NOT Desktop.
The problem is on the Android!!
So whatever code you're using for webdav for the Desktop-plugins, these afaict are 100% syncing and working correctly.
^ surprised !?
The problem is the SAME URL setting in the KIWI(Android) setup, is causing the red-error to show-up.
I will get to this later sometime to see if there is a tcpdump and lock-file getting made by the Android plugin.
@marcelklehr commented on GitHub (Nov 18, 2021):
Are they using the same floccus version?
@marcelklehr commented on GitHub (Nov 18, 2021):
Can you please post the exact error message here?
@swestlake commented on GitHub (Nov 18, 2021):
same version 4.8.3
4.8.4 is not yet showing up on the chrome-extension shop..
@swestlake commented on GitHub (Nov 18, 2021):
I am using another Android -- (and in another lan setup), and it passes with a simple bookmark sync. (only a few bookmarks in it)
I am not 100% sure what was happening with the other Android device..
I will try to replicate the red-error message -- as there were many bookmarks in the original setup.
@swestlake commented on GitHub (Nov 19, 2021):
ran it on my latest setup --
A) 1 Desktop Chromium (containing ~1000 bookmarks)
B) 1 Android Kiwi
Server: Owncloud 10.5,
Test 1: No Bookmarks.xbel on server -- Create the bookmarks file on webdav server.
(reminding to self -- I know from unmentioned coverage here is that for other desktop machines, they are able to sync with this newly created bookmarks.xbel without issue, so there is no need to consider these as being part of the test)
Test 2: Test first-sync run on (B) (Kiwi on Android)
I check new bookmarks in Kiwi, and there is nothing changed.
*** Despite Kiwi/Floccus saying success, there is zero new bookmarks showing in this app. ***
Test 3: Delete Bookmarks.xbel from server, and re-run Test 1:, followed by Test 2:
^ This triggered a reset for Kiwi? --- apparently this did something for Kiwi to finally allow new bookmarks into it.
All tests say ok successful with a green checkmark, even though Test 2 is actually failing to show any new bookmark. (it fails to show any one new bookmark from a library bookmarks.xbel file containing a thousand bookmarks.)
There is a logic bug in the Android chrome-extension, as I can repeat the successful syncs...
I am not sure if I can replicate the "first-run" sync bug...
.. but I can replicate the "first-sync" bug presumably, if I completely wipe out the entire browser and user cache from Android, and start the whole thing over again.
^^ After the first-run failure (despite Kiwi/floccus saying "ok" successful), -- no matter how many times I would click on a manual sync, there would never be any new bookmarks.
(Whether this is irrelevant, maybe some food for thought:: I have zero bookmarks in Kiwi -- whether Kiwi comes with some default or not, I just delete any default bookmarks that may have been lingering when Kiwi browser is first installed. trivial, not important, though Kiwi remains at "0 bookmarks" continuously despite how many times I make changes to bookmarks.xbel from the Desktop browser.)
the Kiwi android plugin can clearly access and make the .lock, but it is using something incorrectly prevently it from adding new bookmarks.
Between Test 2: and Test 3: , I forced the Kiwi-Android plugin to create the new bookmarks.xbel file, deleted it from the server, then went to Test 3:.
^ The floccus extension as a brand new install should be "syncing bookmarks" on its first sync -- but it doesn't perform this (and again.. even though it says "successful" with the green checkmark).
..
The settings of the plugin, trying to use the default settings to keep things simple..
-> all settings are identical between Desktop Browser and Kiwi/Android.
The settings differ from the application default in only-> URL, username, password and bookmarks file path.
the url I am testing is:
https://domain.com/remote.php/dav/files/_username/
(I am using a validated Lets Encrypt certificate, so Android doesn't give warnings on any self-signed certificates which aren't being used)
the bookmarks file path is:
"test/bookmarks.xbel"
-- and when a lock is noticed, this file appears as: "test/bookmarks.xbel.lock"
I joggled between Test 2: and Test 3: --- maybe once or twice... and the sync finally succeeds with "shown bookmarks" along with the standard green checkmark, etc.
so it is the first time I am noticing a successful sync on Android...
webdav looks very stable afaict, but I am not using anything like the specialized Nextcloud-Bookmarks service... it's just using the webdav file storage -- and seems to hold relatively well as I can see ".lock" added to the bookmarks.xbel filename whenever changes take place.
the webdav is owncloud 10.5..
the Android floccus extension is version 4.8.3, and
the Desktop/Chromium floccus extension is also version 4.8.3
(maybe some of these issues have been addressed for v.4.8.4? -- last I checked it is not yet downloadable from the chrome-add-on store)
however it is very noticeable that the Desktop browsers sync get the new bookmarks from bookmarks.xbel on their very first sync.... no additional secondary manual syncs are needed -- so the Desktop browser's floccus add-on have a better sync built in them.
reflecting back around the time of ""Test 1:"" -- no matter how many times I would click on a "manual sync" in the Kiwi-floccus extension, there would never be new bookmarks added to the Kiwi browser -- even though there is always the green check-mark saying successful. It really meant "0 bookmarks" were added(when in fact there are 1000 bookmarks residing in the 192K sized file on the webdav server) -- there clearly are bookmarks on the server, it is just that the floccus-extension has trouble determining these new bookmarks on its "first-run".
On consecutive runs later(after deleting bookmarks.xbel repeatdly) --- with no changes to the floccus settings, the floccus extension is finally able to sync and ADD new bookmarks for Kiwi.
I sound a little repeated in the above observation, but I am doing this because there's lack of feedback for webdav -- surprisingly it is working quite well I might say.
thanks for letting me elaborate a little more on this.. hopefully I didn't try to create too many confusing observational notes, it is only what I can observe from the front-end interface.. of what is a relatively stable setup I have here..
not many people -- I'd say not enough people know that this can work relatively well on webdav -- surprises me as well... I thought it would be crashing a lot more than this..
so far it is pretty stable.
I have yet to use it as a daily driver, I just installed/tested it -- and I am of course sticking with the owncloud-official docker images only. I don't know why people do not resort to testing things with "official" docker images from their respective projects, and I think they should, as it will force everyone to test more of the same server setup..
(perhaps this project can also promote the idea of supporting official images as this also can make the troubleshooting a lot easier)
keep up the great work
thanks!!
@stale[bot] commented on GitHub (Dec 3, 2021):
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
@github-actions[bot] commented on GitHub (Mar 20, 2023):
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.