chrisero / vocab-forager Goto Github PK

Every time VocabForager defines a highlighted text, it opens a new tab using the selected dictionary site. This can result in a pore user experience when looking up several different highlights. It can also cause performance issues, as each tab spins up a new process by default.

To improve the dictionary search feature, we should implement (at least) one of 2 UI changes:

1. Open up a new tab if not already done, but for future highlights, use the same tab. Ideally, whatever method we use should allow users to visit the previous definition page queried using the back button; the forward button should allow users to visit the newer definition page queried.
2. Open up some "frame" inside the current webpage with the definition page every time user queries for definition. Frame should close and reopen every time a new definition is queried for.

Right now, extension works by waiting for some time (e.g. 800 milliseconds) and the highlighting text in website. This works well for static websites whose content is finalized by that time, but not so well for dynamic pages (those whose DOM may change over time, or at least after the expected length). This would result in a lot of text getting placed in missing section unnecessarily.

To resolve this issue. I propose adding some listener to see if the DOM changes (for reasons other than highlighting) and if so, perform a search (at least on the changed DOM nodes) for text in missing and highlight if found.

Not sure if this is a real problem the at needs fixing.

Right now, all highlights are done with a yellow background and the text contents retain the original source styling, including color. This results in text being illegible in dark-themed sites. Please see here as an example.

This ticket is to resolve this issue, ideally with adding custom highlight styling Add functionality to change the styling of highlighted text at a page-level. These changes should persist across sessions (stored in non-volatile storage).

Sometimes, the extension spins up a new define tab even when one already exists. This behavior may even happen when on the same webpage or when moving across different webpages. This is bad since it makes the fix for this issue 27 incomplete

I suspect that the issue is that the service worker is restarted periodically as described here, it is listed as issue chromebug1152255

With last update, background-script/web-worker no longer deletes sites for which there are neither any missing words nor any highlighted words. This functionality ought to be reintroduced, as it was removed by mistake

Instead of using url of a webpage in sites-page, it may be better to display its title. This would reduce the amount of lines needed to display a web page link and would make the page more human readable.

Allowing textless highlights allows for accidental highlights that cannot be easily removed (without removing entire site data). This is a bad user experience.

As discussed in issue 31, we are having issues, likely, due to the way Chrome restarts the background-script web worker after 5-or-so minutes of inactivity. In addition to the aforementioned issue, there also appear to be hick-ups with simple usage of the extension: activating extension does not immediately show highlighted words and some highlight commands may be missed.

These last few issues are likely due to primitive error handling, which avoids the usage of locks. If the Chromium bug is not addressed in a timely manner, we may be forced to use such techniques, at least for setting up the db connection

Consider choosing alternative storage medium for SiteData:

• https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API

Improve how highlighted sites are grouped. One idea is have 2 pages, one to select host+protocol and the second to select sites belonging to that host