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

Import a backup fails while export is working fine #2966

Closed
FeBe95 opened this Issue May 27, 2018 · 11 comments

Comments

Projects
None yet
3 participants
@FeBe95

FeBe95 commented May 27, 2018

What I've tried

  • tried all checkbox combinations
  • progress bar stuck at value 32 of 58
  • restarted FF multiple times, doesn't help
  • tested on two computers
  • moved around zip file to multiple locations on both devices

Symptoms

multiple times this error text (see also #2964):

22:33:18.618 [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIContentPermissionRequest.principal]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: jar:file:///C:/Program%20Files/Mozilla%20Firefox/browser/omni.ja!/components/nsBrowserGlue.js :: prompt :: line 2998"  data: no]  (unbekannt)
22:33:18.618 NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIContentPermissionRequest.cancel]  nsBrowserGlue.js:3022

once this error text at the end:

22:33:18.671 TypeError: zip.file(...) is null  import.js:118:19

Version info

Firefox 60.0.1 (64-Bit)
Greasemonkey 4.4.0
Windows 10, 64-Bit, 1803 Build 17134.48

@arantius

This comment has been minimized.

Collaborator

arantius commented May 28, 2018

The rest seems irrelevant but the zip.file() reference is importing a require.

Can you share the backup ZIP that does this? If it's sensitive, privately to me (email this username at gmail.com)?

@FeBe95

This comment has been minimized.

FeBe95 commented May 28, 2018

Yes, this might be the issue here. I tracked it down to a script which requires jquery. I attached it below

GM Backup.zip

Edit:
I searched for the require meta in all of my scripts, removed the resulting ones and now the whole backup gets imported correctly. These were the results in multiple user scripts - I see no pattern in the urls (like only https/http):

// @require     http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.js
// @require     http://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js
// @require     https://gist.githubusercontent.com/asfaltboy/8aea7435b888164e8563/raw/caf6a507c36285e71f5fc9ab9972cc64bb64285c/css_path.js
// @require     https://raw.githubusercontent.com/fczbkk/css-selector-generator/master/build/css-selector-generator.js
// @require     https://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js
// @require     https://raw.githubusercontent.com/ngs/jquery-selectorator/master/dist/selectorator.min.js
// @require     http://code.jquery.com/jquery-1.11.1.min.js

@arantius arantius added this to the 4.5 milestone May 28, 2018

@arantius

This comment has been minimized.

Collaborator

arantius commented May 28, 2018

Thanks! I haven't reproduced yet but this is just the right detail, so I'll figure it out.

@arantius

This comment has been minimized.

Collaborator

arantius commented May 31, 2018

When I download that exact zip and try to import it, it does fail.

But when I take the .user.js out of it:

// ==UserScript==
// @name        Test
// @include     *
// @require     http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.js
// ==/UserScript==

alert("test");

Save that (over a "New User Script..."), and export a backup, I get:
Greasemonkey_backup_20180531_150011.zip, which imports just fine.

What exact version of Firefox and Greasemonkey are you running? On which operating system?

@FeBe95

This comment has been minimized.

FeBe95 commented May 31, 2018

Version info
Firefox 60.0.1 (64-Bit)
Greasemonkey 4.4.0
Windows 10, 64-Bit, 1803 Build 17134.48

I manually created a new script like you explained and yes it works just fine. But the @require jquery script gets exported into the zip as well. This doesn't happen for my other scripts that have a @require statement. It might be due to the fact, that I originally created these scripts with GM 3 and they were automatically imported to GM 4.
I also noticed, that some of the old scripts are not exported like /my script foo/my_scripts_foo.user.js but they use their original name from GM 3: If a script was saved as my script foo and later renamed in the @name tag to my script bar, the user.js filename stayed the same in the gm_scripts folder. They now are still saved that way (e.g. /my script foo/my scripts bar.user.js) and sometimes even without the user part. I don't know if this is an important information, I just wanted to let you know that there might be some compatibility issues for exporting old GM 3 scripts. Maybe it would be good to generate a "clean" copy for exports or even better to clean up naming, required scripts and other "old" script parts in the database and not only during exporting (if this is possible anyhow without losing any critical/needed code and data).

Thank you for all the work and time you put into this project! 👍

@Sxderp

This comment has been minimized.

Contributor

Sxderp commented Jun 1, 2018

@FeBe95 , You should treat the gm_scripts folder as archived content. As a WebExtension (GM 4.x) there is no filesystem access and that folder cannot be read nor written to.

@FeBe95

This comment has been minimized.

FeBe95 commented Jun 1, 2018

@Sxderp Yes, I am aware of that. I just wanted to mention it, as the folder structure of the exported backup zip file seems to be the same as the old gm_scripts folder.

@arantius

This comment has been minimized.

Collaborator

arantius commented Jun 1, 2018

... the user.js filename stayed the same ...

The ZIP export uses the original download URL to form the file name, not the @name, so this is expected.

I think the best thing to do here is just add some error checking/handling. If we caught and ignored this failure, we'd just (try to) download the @require again -- in this case it would be fine. (But it's possible that URL no longer resolves, or serves something different/incompatible now.)

@FeBe95

This comment has been minimized.

FeBe95 commented Jun 1, 2018

This makes perfect sense, yes. Re-downloading all requirements should work - as long as the sources still exist. If not (so the required files are not included in the zip but the @require tag is still in the code of the exported scripts) the import function could catch these cases and add some kind of error log / output to let the user know, that the affected scripts may not work as expected and he/she needs to review the code.

For me the question still remains why the required sources of the old scripts didn't get exported just like those of new ones. I doublechecked all sources and they definitely still exist (mostly jquery). None of my old scripts got their additional sources included in the backup zip, not only some specific ones.

@Sxderp

This comment has been minimized.

Contributor

Sxderp commented Jun 1, 2018

For me the question still remains why the required sources of the old scripts didn't get exported just like those of new ones.

Migration may not migrate downloadURL properly? Kinda late to fix this though.

arantius added a commit to arantius/greasemonkey that referenced this issue Jun 7, 2018

Skip import of missing files.
Handle the previous export failure as gracefully as we can.

Refs greasemonkey#2966
@arantius

This comment has been minimized.

Collaborator

arantius commented Jun 28, 2018

At this point, it's not terribly likely that a better fix happens any time soon.

@arantius arantius closed this Jun 28, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment