SDK-based add-ons that hard-code absolute paths to files in their packages will break with the 1.4 update, due to changes in the way files are handled. More details here: https://wiki.mozilla.org/Labs/Jetpack/Release_Notes/1.4#Known_Issues The Jetpack team want to identify these add-ons so that their developers can be contacted about it. What we need is a validator compatibility test that detects these cases and generates an error. Then we can run a fake Firefox 11 bump where only the developers with failing cases will be contacted. We would need to later remove this test when the real Firefox 11 validation is run. The error message can be something like "This add-on references absolute resource URIs, which will break in the 1.4 SDK". Jeff should be able to provide an example of an add-on that wouldn't pass this test.
Matt: a slightly more refined pattern would be: /\"resource:\/\/[\w\-]+?\-data\// eg, all uris would *also* include the string '-data/' in the string, as the files being referenced are all contained in the 'data' directory of the Addon. It would also be great if the script would ignore the addon-kit and api-utils directories in a given addon as these will produce some false positives.
(In reply to Jeff Griffiths from comment #2) > It would also be great if the script would ignore the addon-kit and > api-utils directories in a given addon as these will produce some false > positives. Can you give an example of one of these URIs?
How many add-ons are we talking about? Will MXR not work for this?
(In reply to Wil Clouser [:clouserw] from comment #4) > How many add-ons are we talking about? Will MXR not work for this? We tried using MXR, but it wasn't sufficient since there are too many matches coming from SDK library files and its regex features are very limited.
https://addons.mozilla.org/en-US/firefox/addon/read-later-fast/(In reply to Matt Basta from comment #3) > (In reply to Jeff Griffiths from comment #2) > > It would also be great if the script would ignore the addon-kit and > > api-utils directories in a given addon as these will produce some false > > positives. > > Can you give an example of one of these URIs? resources/jid0-ayilkqe9scrtfyorhwez2iaxcro-api-utils-lib/self.js [https://mxr.mozilla.org/addons/source/303585/]
> DO NOT scan into these directories: Keep in mind that we currently don't scan any files in an add-on if it matches a hash from a file in the SDK.
Leveraging the bulk validation for this is kind of scary and not particularly related. We should just make a command that selects the right add-ons, runs validation on them, and prints the output. I'm assigning to mbasta for the logic in the validator for now.
Assignee: nobody → mattbasta
Priority: P2 → P3
Target Milestone: 6.3.8 → 6.3.9
Done https://github.com/mozilla/amo-validator/pull/118 So here's how this works: any Jetpack add-on that contains the issue in this bug will throw a compatibility error, even if no versions to test for compatibility have been selected. This means that a bare compatibility run (with no "forced" version, like we'd use to test for compatibility with Firefox) will yield all add-ons that aren't compatible with the SDK 1.4. If this is going to muck with things, I can get rid of the compatibility error and the error can be detected by iterating the messages like this: any(m["id"][-1] == "jetpack_abs_uri" for m in messages)
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.