Update webext storage on moz-central

[bendk]

Vendor in the newest version of webext storage into moz-central. This will be nice since it has the new database corruption handling, but the real reason to do it is so I can get some experience in using mach vendor rust.

┆Issue is synchronized with this Jira Task ┆Story Points: 1 ┆Sprint End Date: 2021-09-30

[bendk]

I'm running into a couple issues with this one:

Sometimes the RunCbindgen.py generate_metadata command fails with an error because it's running cargo metadata --frozen. I'm not sure exactly what triggers this issue, but I've so far been able to workaround it by manually running cargo metadata from the command line. I think I should be able to figure this one out once I figure out the next one, but if anyone recognizes this issue and can point me in the right direction, that would be great.

---

Updating the url crate is causing failures in several test suites having to do with "upgrading the storage" (for example test_upgradeFromPersistentStorageDirectory). I'm pretty sure this is happening because upgrading url is casing the mozurl behavior to change causing errors like this:

 0:03.33 CRASH: pid:1684117. Test:dom/quota/test/xpcshell/upgrades/test_upgradeFromPersistentStorageDirectory.js. Minidump analysed:False. Signature:[@ libxul.so + 0x647d621]
Mozilla crash reason: Invalid principal infos found: originNoSuffix (file://///aaaaa.aaaa) doesn't match passed one (file:///aaaaa.aaaa)!, baseDomain (aaaaaaaaa://aa-aaaaaaaa/) doesn't match passed one (aaaaaaaaa://aa-aaaaaaaa)!

I have this narrowed down to some specific URLs that seem to be parsed differently. Is there a test suite that I can use to verify that URL parsing hasn't changed?

Also, is mozurl the main URL parsing library or a secondary one? I would expect to other test errors if I broke URL parsing.

---

@ncalexan Janet says that you might be interested in helping me out on with this one. If you have any ideas on the above two issues it would be much appreciated.

[ncalexan]

@bendk hi! I will have to redirect this eventually, but let's do one round of debugging. Can you push your patch after ./mach vendor rust to Phab and to try so that I can take a look and so we can see these crashes in automation?

My expectation is that there is some small parsing change in url that we'll need to characterize and then loop in one of our networking folks -- perhaps Valentin, who's committed to url. But let's do one step more together first.

[bendk]

@ncalexan Here's my last try run: https://treeherder.mozilla.org/#/jobs?repo=try&revision=c1beef3982a6a817544b4fb26285167cb276086e. It's a few days old at this point, but I think it covers all the issues.

BTW, one of the URLs that I've noticed being parsed differently is indexeddb://fx-devtools/ (or something close to that, I haven't totally isolated the issue yet). - Base domain before upgrade: indexeddb://fx-devtools/ - Base domain after upgrade removes the trailing slash: indexeddb://fx-devtools

[mhammond]

I think I worked out roughly what's going on here, so opened bug 1734538.

[data-sync-user]

➤ Janet Dragojevic commented:

🚩 Flag added

blocked on urllib updates in Desktop

[bendk]

webext storage has been updated fairly recently (https://hg.mozilla.org/mozilla-central/rev/12ee41f70894e7a9ee03458bb554aecd9d0016ea), so I think we can close this.