Closed lftl closed 7 years ago
Forgot to add the error message although it's not particularly helpful
Error: An unexpected error occurred
Possibly unhandled rejection: {}
Could you try it in a fresh profile? I've been doing my development work on Nightly and I didn't encounter that problem with 57 or 58. By testing a new profile it should tell me if its something in FF that changed, or if the addon config is broken.
A clean profile worked fine.
Hmm, given this issue and #73 it seems like there is some way in which the config gets corrupted. If you still have the corrupted profile can you export the settings in "Backup & Restore" and post it here?
If the Backup button doesn't work due to #60 let me know I will give you an alternative way to export the settings. Thanks for helping me debug this issue.
The Backup and Restore tab never shows up on my main profile.
Oh, duh. My bad. Try this instead:
1) Open the devtools on the busted setting tab. (Ctrl + Shift + K)
2) Type: JSON.stringify(modules.settings)
3) Copy and paste the output into this issue.
Here you go:
"{\"gestureButton\":2,\"gestureTimeout\":2000,\"gestureFidelity\":10,\"drawTrails\":true,\"trailFidelity\":10,\"trailWidth\":2,\"trailColor\":\"purple\",\"showStatusText\":true,\"statusTimeout\":2000,\"mouseMappings\":[],\"userScripts\":[],\"sawXSSWarning\":false,\"wheelGestures\":false,\"wheelMappings\":{\"up\":null,\"down\":null,\"left\":null,\"right\":null},\"scrollDuration\":500,\"scrollAmount\":100,\"nextTabWrap\":true,\"newTabUrl\":null,\"newWindowUrl\":null,\"newPrivateWindowUrl\":null,\"useRelPrevNext\":true,\"insertTabIsActive\":false,\"insertRelatedTab\":true,\"zoomStep\":0.1,\"statusTemplate\":\"<div style=\\\"display: block; position: fixed; bottom: 0; right: 0; z-index: 2147483647\\\">\\r\\n <div style=\\\"background: #fff; border: 1px solid #ccc; color: #333; font-family: sans-serif; font-size: 12px; padding: 2px\\\" data-mg-status></div>\\r\\n</div>\"}"
Also after forcing the UI to show through Angular, here's a slightly improved stack trace:
@moz-extension://1cf4b900-0c79-42c3-908a-71ab77930e95/options/options.js:158:5
invoke@moz-extension://1cf4b900-0c79-42c3-908a-71ab77930e95/options/lib/angular.min.js:44:355
zf/this.$get</</<@moz-extension://1cf4b900-0c79-42c3-908a-71ab77930e95/options/lib/angular.min.js:94:330
q@moz-extension://1cf4b900-0c79-42c3-908a-71ab77930e95/options/lib/angular.min.js:69:334
f@moz-extension://1cf4b900-0c79-42c3-908a-71ab77930e95/options/lib/angular.min.js:62:288
f@moz-extension://1cf4b900-0c79-42c3-908a-71ab77930e95/options/lib/angular.min.js:62:305
da/<@moz-extension://1cf4b900-0c79-42c3-908a-71ab77930e95/options/lib/angular.min.js:61:416
c/</<@moz-extension://1cf4b900-0c79-42c3-908a-71ab77930e95/options/lib/angular.min.js:22:157
$eval@moz-extension://1cf4b900-0c79-42c3-908a-71ab77930e95/options/lib/angular.min.js:149:510
$apply@moz-extension://1cf4b900-0c79-42c3-908a-71ab77930e95/options/lib/angular.min.js:150:215
c/<@moz-extension://1cf4b900-0c79-42c3-908a-71ab77930e95/options/lib/angular.min.js:22:115
invoke@moz-extension://1cf4b900-0c79-42c3-908a-71ab77930e95/options/lib/angular.min.js:44:355
c@moz-extension://1cf4b900-0c79-42c3-908a-71ab77930e95/options/lib/angular.min.js:22:36
Uc@moz-extension://1cf4b900-0c79-42c3-908a-71ab77930e95/options/lib/angular.min.js:22:332
xe@moz-extension://1cf4b900-0c79-42c3-908a-71ab77930e95/options/lib/angular.min.js:21:1
@moz-extension://1cf4b900-0c79-42c3-908a-71ab77930e95/options/lib/angular.min.js:333:241
b@moz-extension://1cf4b900-0c79-42c3-908a-71ab77930e95/options/lib/angular.min.js:38:201
I wonder if this is a browser.sync issue. I don't use a FF account to sync anything across computers.
From the stack trace it appears to be an issue in the promise chain that loads the settings. The curious part is that mouseMappings is an empty array, and it should get populated with default mappings when the addon is first installed.
If you don't mind, try pasting the following into the console to try and figure out what the exception is that is causing the promise chain to reject.
modules.settings.loaded.then(v => console.log('ok', v), e => console.log('err', e))
var angSetting = angular.element(document.body).scope().settings;
angSetting.load().then(v => console.log('ok', v), e => console.log('err', e))
Your comment about sync being the issue popped up while I was writing this reponse, and that is where my thoughts were going as well. If the sync API is throwing an exception perhaps one of those two statements I provided will print it. I don't use sync either, but it never caused me an issue with the storage.sync API.
No dice, both of those lines just throw the same exception if I try them after the options pages has loaded. I set the debugger to break here and played around a bit.
browser.storage.sync.get() with no options works ok, but browser.storage.sync.get({'foo': 1}) throws an error, and I couldn't get it to give any useful error message as to why.
Did you try something like?
browser.storage.sync.get({'foo': 1}).catch(err => console.log(err));
Also, have you looked in the browser console (Ctrl+Shift+J) in case it logs more information in there?
Nothing different:
browser.storage.sync.get({'foo': 1}).catch(err => console.log(err));
Promise { <state>: "pending" }
Error: An unexpected error occurred
Stack trace:
modules.settings<@moz-extension://8cd08ee0-065c-4fc7-867d-0aa016c57629/background/settings.js:53:7
@moz-extension://8cd08ee0-065c-4fc7-867d-0aa016c57629/background/settings.js:8:21
On Mon, Oct 16, 2017 at 07:22:21PM +0000, marklieberman wrote:
Did you try something like?
browser.storage.sync.get({'foo': 1}).catch(err => console.log(err));
Also, have you looked in the browser console (Ctrl+Shift+J) in case it logs more information in there?
-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/marklieberman/foxygestures/issues/76#issuecomment-337005344
I'm chatting with some devs in Mozilla's IRC and they have suggested checking about:sync-log for any errors.
Also, for the sake of getting help from IRC could you open both the web console and browser console, open the settings page and get the error, and then take a screenshot and upload it here. Thanks.
Sorry for the delay in response. I've upgraded to the latest beta version and I'm no longer seeing the issue. It looks to me based on the little looking I did at the web console before upgrading that it was an internal issue in FF beta.
This does seem to be related to Firefox Sync. I have run into this problem on the newly released FF57, but it does not appear in 58.0b4 Developer Edition that I've been using to develop and test pull-request #109.
To reproduce here on Ubuntu 16.04 with gnome:
If I sign in to a Firefox Sync account, the problem goes away. Logging out of the sync account does not make the symptom re-appear. If in between steps 2 and 3 I go to about:debugging and start debugging Foxy Gestures I see this as the initial contents:
Then I clear the contents of the develtools console and execute step 3. That shows this console:
about:sync-log shows the contents of file:///home/peter/firefox.tmp/weave/logs/ and it is empty
If I sign in to Firefox Sync and try again, I get this console:
Again, none of this is a problem with FF 58.0b4 Developer Edition
@pmorch That's some good investigation. Maybe now I can get the devs on IRC to look at this issue again. Strange that I never encountered this issue despite installing it on FF57 on at least 3 different machines.
@pmorch I'm incredibly interested in this "no such table: collection_data" error. We've seen it in some of our telemetry and I had no idea what causes it. My best guess is that it's an incomplete initialization of the storage.sync SQLite database, but I had thought it could only happen due to a user shutting Firefox down unexpectedly. I have no idea why it would go away once you sign in to sync, either! The fact that you can reproduce it reliably is great. I don't have time at the moment to look at this but I hope to get a chance in the next week to see if I can reproduce it.
Hi @pmorch, I just tried to reproduce this using the steps you posted but have had no luck so far. My "work" computer is Fedora and I have at this moment Firefox 56 installed and Nightly (59.0a1), and neither of them demonstrate the problem. On my "home" computer (Ubuntu GNOME) I have Firefox 57 and it doesn't do it either. Just to make sure I have the right steps here:
I don't see any Sqlite errors like the ones you saw.
A normal preferences page comes up, with tabs "General Settings", "Built-In Commands", "User Scripts", etc. and (under General Settings) options like "Gesture Button", "Gesture Timeout", etc.
If you're still able to reproduce it, could I ask you to open the browser console (Ctrl-Shift-J or developer -> browser console) and see if you see any Sqlite errors there, before you even install Foxy Gestures? You might also try sqlite3 foxygestures.profile/storage-sync.sqlite
and then .schema
at the prompt. If things are working correctly, it should be:
CREATE TABLE collection_data (
collection_name TEXT,
record_id TEXT,
record TEXT
);
CREATE TABLE collection_metadata (
collection_name TEXT PRIMARY KEY,
last_modified INTEGER
) WITHOUT ROWID;
CREATE UNIQUE INDEX unique_collection_record
ON collection_data(collection_name, record_id);
But what you're saying is that it isn't, and I'm really curious why. If you have the resources to build and test a patch, or if maybe there's a way for me to build one for you, the thing to try is to add statements like the following to kinto-storage-adapter.js, in the _init
method:
diff --git a/services/common/kinto-storage-adapter.js b/services/common/kinto-storage-adapter.js
index 2b639e58fc00..acf4cd6254d9 100644
--- a/services/common/kinto-storage-adapter.js
+++ b/services/common/kinto-storage-adapter.js
@@ -218,6 +218,7 @@ class FirefoxAdapter extends Kinto.adapters.BaseAdapter {
if (schema == 0) {
for (let statementName of createStatements) {
+ dump(`running ${statementName}\n`);
await connection.execute(statements[statementName]);
}
The only theories I can come up with about why the Sqlite file isn't being initialized are all very serious -- like hard drive failure -- and they're the sort of thing I think you would have already noticed, and even if you didn't, I can't come up with any reason why you wouldn't hit them in 58. Maybe something very low-level in the Sqlite code got changed? I'm not sure who would know more.
Ah, @andymckay pointed me at https://bugzilla.mozilla.org/show_bug.cgi?id=1411691, which is maybe the same thing and we didn't make much progress there either.
@glasserc : I'm so sorry for taking so long to respond. I wanted to do a little more investigation because I also saw in some similar circumstances that it didn't fail and I'm a little confused about that.
But now I just installed a fresh Ubuntu 16.04 64-bit VM in VirtualBox, and made sure it was upgraded, so that it has FF57. These steps create the "Empty Options Page" problem with the errors above:
I can provide you with the ~ 6GB virtual machine in a tar.gz og zip file, but I literally just installed it, updated it and ran firefox to reproduce the problem. Let me know if you'd like my virtual machine.
Sorry for dropping off the radar on this one. I suspect that this is the same as https://bugzilla.mozilla.org/show_bug.cgi?id=1411691, and that something is wrong with the way the storage-sync.sqlite database is getting initialized by competing threads. I will try to work on it in the linked bug.
I'm using the beta build of FF 57 on linux and when I open the preferences page I get the header and then nothing else. Stack trace from the console: