search

rthaut / deviantART-Filter

A browser extension that allows you to filter DeviantArt by user, keyword, and/or category.
https://rthaut.github.io/deviantART-Filter/
GNU General Public License v3.0
31 stars 1 forks source link

Compatibility with Chromium #10

Closed ctag closed 7 years ago

ctag commented 7 years ago

This userscript doesn't work with the current version of Chromium, as @require and GM_getValue are deprecated.

A workaround would be to use localStorage to replace getValue/setValue, but rewriting without jQuery would be a pretty big chore.

Any other ideas? If I rewrite without jQuery, would you be willing to help test browsers and eventually pull a patch?

rthaut commented 7 years ago

I'm probably going to spin off a few issues for this, but here's my thoughts:

GM_getValue/GM_setValue replacement

I think indexedDB is probably a better long-term replacement, given the size and functional limitations with localStorage. That said, localStorage is quite a bit simpler (and synchronous, so it matches the existing logic), so it may be a good transition step.

My bigger concern is actually how to help users migrate (without having them manually export their filters then re-import through the settings). Currently everyone using the script will be employing Greasemonkey or Tampermonkey, which allow @grant GM_getValue/GM_setValue. Obviously they could continue to use the script in Greasemonkey/Tampermonkey after switching to an HTML5 storage solution, but AFAIK there's no way to pull data that was stored with GM_setValue using anything other than GM_getValue...

jQuery Dependency w/o @require

Rewriting the script without jQuery is probably not a worthwhile endeavor. I'm not sure if userscripts can manually inject a <script src="..."></script> tag into the document anymore; that used to be the standard solution years ago, but I think cross-site content restrictions have made that obsolete. It is probably best just to append the minified jQuery code directly to the userscript file. That would increase the script size, but I think jQuery Slim is sufficient, so using that instead would help. A build tool like gulp could automate the step to append jQuery, so the source file(s) would stay clean.

Web Extension

Personally, I would rather convert the userscript into a proper browser extension, now that Firefox and Chrome both utilize Web Extensions. In general, userscripts are relics of a time when proper browser Add-Ons/Extensions were cumbersome to create and maintain, but these days it is pretty much just an extra manifest.json file to inject the JS script(s).

There would also be some added benefits, like using the exposed APIs to store data such that it is synchronized across computers through the user's browser cloud profile, as well as maybe pulling the manage/settings modal out of the site into a standalone page/panel in the browser.

Again the big concern here is helping existing users migrate. Manually migrating is possible, since they can export/import filters through the settings section, but that can definitely be overwhelming to novices.

I actually already have a beta build for this; I just need to work on the packaging process so that it can be distributed.

rthaut commented 7 years ago

Closing this now.

I don't see a reason to maintain a second userscript version that doesn't utilize GM_setValue and GM_getValue for storage, since the web extensions provide that functionality now.

If there is ever a way to retrieve data stored by GM_setValue through standard/native JS APIs, then the userscript should be updated accordingly (assuming it is still being maintained at that time).