Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

All styles missing in manager page though present in Indexed DB (normal browsing, not private) #546

Closed
ocumo opened this issue Nov 7, 2018 · 4 comments

Comments

@ocumo
Copy link

ocumo commented Nov 7, 2018

  • Browser: Firefox 63.0 (64-bit)
  • Operating System: Kubuntu 18.04
  • Screenshot:
    image
    All my installed styles suddenly "disappeared" from the manage page. This is not the Private Window mode and I have not changed any privacy settings since years.
    The Indexed DB section in the Dev Tools show some parameters as null, but that is exactly how they are in my working Chromium because they are totally local: md5Url, originalMd5, updateUrl and url are null, and all the others, as far as I can tell, are normal. In fact, in the Indexed DB section I can see that all the other parameters are also the same as in Chrome (originally written in Firefox, then exported to Chromium).

Although I have seen the closed bugs #528 and #530, those referred to Chrome 72.0.3592.0, and in my case I have had no issues with Stylus yet in my Chromium because it's at version 70.0.3538.77. I am opening this bug here because neither of those closed bugs will help Firefox users because their titles and contents point to Chrome. It is important that there is a bug with a title clearly saying "styles missing" without referring to any browser in particular.

I do have a backup, but before "fixing" it with restoring a backup, I think it is more important to get more information and support for users and clear statements of what actions are necessary to get things working. Not all users of this extension are JavaScript developers. So please don't dismiss this bug with "somebody else's problem" or with an ultra "kind" that's even dumber remark... if that is not asking too much. Thanks!

Edit: I forgot to mention, about what is suggested in a comment in #528:
image
So, the name of the BG.dbExec function is dbExecChromeStorage and BG.cachedStyles.list is an empty array.

@eight04
Copy link
Collaborator

eight04 commented Nov 7, 2018

It seems that for some reasons, your Stylus decided to drop the original indexed DB and switched to the storage API. That's why your styles are still there but the list is empty.

Try executing the following command and restart the browser to see if Stylus can switch it back:

BG.localStorage.dbInChromeStorage = false;

@ocumo
Copy link
Author

ocumo commented Nov 7, 2018

Thank you very much for your prompt and very useful reply. I have done as you said and after restarting Firefox, everything looks now normal in the manage page: all my styles are back, and they are doing what they are supposed to do.
So, my actions were these:

  1. Open the Dev Tools console and run this command: BG.localStorage.dbInChromeStorage = false;
  2. Restart Firefox, go to the Stylus manage page and see that styles are there.
  3. Open the Dev Tools console again and try the commands I mentioned in my original post and suggested by you in another thread:
    image
    Now, the name of the BG.dbExec function is dbExecIndexedDB and BG.cachedStyles.list contains what it should, i.e., an array of objects, each of which are my styles.

Thanks again for your help. I hope that this situation doesn't repeat, and although the cause is not known, at least now I have this information and will use it again if necessary; I hope it can also help others in similar situation. Would you happen to have any additional tips on how eventually this could have happened or what could be done to avoid it?

@eight04
Copy link
Collaborator

eight04 commented Nov 8, 2018

any additional tips on how eventually this could have happened or what could be done to avoid it?

The extension would switch to storage API if it failed to access indexed DB or it can't read saved data:

do {
const done = () => {
cachedStyles.mutex.inProgress = false;
getStyles().then(() => {
dbExec.initialized = true;
window.dispatchEvent(new Event('storageReady'));
});
};
const fallback = () => {
dbExec = dbExecChromeStorage;
chromeLocal.set({dbInChromeStorage: true});
localStorage.dbInChromeStorage = 'true';
ignoreChromeError();
done();
};
const fallbackSet = localStorage.dbInChromeStorage;
if (fallbackSet === 'true' || !tryCatch(() => indexedDB)) {
fallback();
break;
} else if (fallbackSet === 'false') {
done();
break;
}
chromeLocal.get('dbInChromeStorage')
.then(data =>
data && data.dbInChromeStorage && Promise.reject())
.then(() =>
tryCatch(dbExecIndexedDB, 'getAllKeys', IDBKeyRange.lowerBound(1), 1) ||
Promise.reject())
.then(({target}) => (
(target.result || [])[0] ?
Promise.reject('ok') :
dbExecIndexedDB('put', {id: -1})))
.then(() =>
dbExecIndexedDB('get', -1))
.then(({target}) => (
(target.result || {}).id === -1 ?
dbExecIndexedDB('delete', -1) :
Promise.reject()))
.then(() =>
Promise.reject('ok'))
.catch(result => {
if (result === 'ok') {
chromeLocal.set({dbInChromeStorage: false});
localStorage.dbInChromeStorage = 'false';
done();
} else {
fallback();
}
});
} while (0);

But the validation has many steps, we don't know which step failed.

@ocumo
Copy link
Author

ocumo commented Nov 8, 2018

Interesting... so it's actually a fallback function being called, presumably because the getStyles returned promise somehow failed to set things as expected; and I presume that we don't have debug logs that could help to understand what could have gone wrong.

Ok, I don't know the code, but since you guys have prepared for this situation ab-front, at least you are catching the data so that it doesn't fall in the "vacuum" (better in storage API than nowhere), and somehow expected this to eventually happen.

I would guess that this means there is hope that the promise chain could some time in the future be extended to provide some kind of basic information to the user, like a short error message or error code of some kind, so people could refer to it when contacting the experts. Or some kind of logs, or better yet, to use an even better fallback that is transparent to the user, should that magic be ever discovered/invented...

Well, I know the thing with storing data with extensions/add-ons is very complicated and that there are a lot of things you guys are certainly looking at since long time...

Thank you very much for sharing this bit of information. If there is a "next time" for me with this situation, I will try to understand better what exactly could have happened on my side (if anything), such as some extension's update or installation, some Firefox update, etc.

Thanks for this fantastic extension/fork, by the way. It's absolutely brilliant.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants