danilonovakovic / chrome-dynamic-bookmarks Goto Github PK

Basically what's needed is:

• tslint (+ prettier integration)
• extending babel + webpack with adequate plugins
• extending jest?
• turning few files to typescript for testing purposes
• seeing how it affects bundle size and output

I seem to have reached the limit on how many dynamic bookmarks I can have. If I try to create more then 18 then I get a "QUOTA_BYTES_PER_ITEM quota exceeded" error. Deleting a bookmark allows the creation of a new one but still is limited to 18.

version 2.5.0 on Chrome 76.0.3809.100 (Official Build) (64-bit)
Windows 10 Pro 64bit version 1903 (OS Build 18362.295)

It would be great if the user could provide additional information somewhere to bookmark (ex. instead of having just the link and regexp, it would be good if he could have a description describing what the site URL is linking to is about)

Since, in my opinion, the widgets in popup window are taking enough space as it is (and will be even more once I add the ability to chose a parent folder where BM should be saved), this description field should be only available through Bookmark Manager (ex. in Edit window)

Additionally, this field should have a limit of around 100-200 characters so that the user doesn't exceed the allowed size of the local/sync storage

Essentially .prettierrc needs to be added and integrated with .eslint so that formatting is same for all developers.

Also would be usefull to add formatting commands like format to package.json

Manifest v2 is deprecated and will soon be removed by Google, so I must migrate to v3

Is your feature request related to a problem? Please describe.
Some applications have a good document title which stays the same across updating content. It would be powerful to be able to utilize this, especially because on some sites there is no other way of telling which URLs belong together, e.g. because they used some hash-like URL. In those cases this extension cannot be used at the moment.

Describe the solution you'd like
Either of the following solutions would work for me:

• Add a new additional configuration field (below the current "Regular Expression" field) that allows you to provide a regular expression for the document title, with the current document title as default. The two fields should be combined as follows: a webpage matches a bookmark whenever both regular expressions match the page.
• Add a checkbox which makes the bookmark track the document title in addition to the URL regex (default on).

Describe alternatives you've considered

• Use the first proposed solution, but leave the document title regex empty by default. But this decreases the usability of this feature because 1) the page title isn't easily copied and 2) not having to change anything to the default configuration is the most user-friendly. Moreover, I haven't been able to find cases in which the title contains unwanted variability where the default URL heuristic doesn't already have unwanted variability (and manual configuration would thus be necessary anyway).
• Add a checkbox which makes the bookmark track the document title in addition to the URL regex (default off).
• Add a checkbox which makes the bookmark track the document title instead of the URL regex (default on).
• Add a checkbox which makes the bookmark track the document title instead of the URL regex (default off).

Cool extension btw

Dear developers,

Can you please make it possible to load the current website titles of bookmarks in a specific folder?

Use case: When I import into the desktop Chrome the bookmarks I exported from Android Chrome (via this tool: https://android.stackexchange.com/questions/56635/how-can-i-export-the-list-of-open-chrome-tabs/199496#199496), the titles of the newly imported bookmarks are URLs, not the websites' titles.

I appreciate you considering my suggestion.
Thank you for your time.

User should be able to select in which folder he wants to add a bookmark when adding it (instead of putting it to "Other bookmarks" always).

Nice to have (but it can be done later too):

• He should also be able to create new folder (and perhaps subfolders) while looking at where to place the new bookmark

Describe the bug
Automatically generated regural expression is not correct for YouTube playlist

To Reproduce
Steps to reproduce the behavior:

1. Go to https://www.youtube.com/watch?v=H2ZerTdtudk&list=PLtG4P3lq8RHFBeVaruf2JjyQmZJH4__Zv&index=8&ab_channel=Proko
2. Click on popup window of extension
3. Generated regural expression is youtube\.com\/\.\*list=PLtG4P3lq8RHFBeVaruf2JjyQmZJH4__Zv

Expected behavior
Regural expression should be youtube\.com\/.*list=PLtG4P3lq8RHFBeVaruf2JjyQmZJH4__Zv - aka it should be .* instead of \.\*

Describe the bug
id value for the bookmark (regular ones implemented by Google) is an integer that gets incremented whenever new bookmark is created. This is all fine when you are working on a local machine, but the problem arises when user syncs the account. What happens then is that imported/synced bookmarks actually get a new id value assigned to them so it completely messes up the dynamic information as it uses the id field to identify which bookmark it is that regular expression is referring to.

This bug would solve itself if Google decided to use uuid for bookmarks instead of integer, but I am not that lucky :)

To Reproduce
Steps to reproduce the behavior:

1. Add a dynamic bookmark on Machine A
2. Add a regular bookmark on Machine B (before syncing account)
3. Sync account on Machine B
4. Bookmark from step 2 will be tracked instead of bookmark created in step 1 (on Machine B)

Expected behavior
When syncing accounts on a different machine I should be able to sync dynamic bookmarks as well

Desktop (please complete the following information):

• OS: Windows
• Browser Chrome
• Version 87.0.4280.88

Potential solution

The most reliable field I could use to potentially solve this problem is the dateAdded since it is measured in milliseconds and it's unrealistic for the user to create two bookmarks at the same millisecond. On the downside, this solution would decrease performance (as searching by dateAdded is not as fast as searching by id - at least it shouldn't be), but since I think this feature is important I will definitely have to find a solution to this problem

Essentially it's pretty hard to develop components individually for Chrome extension since you rely on the Google API (which is a bit annoying to debug, and usually has a messy structure)

Would be more preferable to utilize Storybook more while perhaps mocking some of the browser calls so that development is easier