Hi,
A month ago, sent add-on for a simple review (https://addons.mozilla.org/ru/firefox/addon/supermegabest/), in the document specified the date in two weeks. Tell me how long we have to wait for results : (
What browser is that in the screenshots of your addon? Or is it a theme on firefox?
Very nice of you to be upfront on what data you collect. Stated in first line very nice.
This addon is present in all browsers, so the screenshot shows the schematic browser window, without reference to any particular browser. This is not a theme, it’s an addon. We can change the screenshots, the screenshots of the browser window Firefox
Oh no it was a cool looking theme so thats why i was asking. Screenshots are fine 
Did you follow their rules yet and remove the eval function? See step 2 of https://wiki.mozilla.org/AMO/Reviewers/Guide/Reviewing which is their guide. Using eval at all will get it rejected.
We don’t understand how you can replace a use of eval. In our base rules are stored as strings containing the rules for obtaining the name of the item from the shop page. The rules are very different from the usual ($(‘h1’).text()) to composite (jQuery(’[itemprop=“name”]’).text() + ‘, ’ + jQuery(’[itemprop=“author”]’).text().trim()). And how can we make obtaining the title product otherwise we don’t know. If you have any ideas how to change it, write to them. More surprising is that for example in Opera Addons asked just to throw a list of all of the rules inside the extension and not take it from the servers. The first time was faced with such requirements …
Firefox is as far as I can tell the only browser that actually cares about how addons affects their users. Firefox requires all addons to be secure and not unduly damaging to performance. My suggestion would be to either email amo-editors@mozilla.org or better visit #amo-editors on irc.mozilla.org to have a discussion there.
OK, thanks
The problem is, what you are doing here is remote script injection - code from your server is effectively running in the context of any website. That’s just not acceptable, even if you don’t have any bad intentions - somebody could hack your server and make the extension turn malicious (like showing ads everywhere).
You need to turn that code into data, even if it is painful. For example, you could be sending JSON data like this:
"example.com": {
selectors: ["h1"]
},
"example.info": {
selectors: ["[itemprop=\"name\"]", "[itemprop=\"author\"]"],
joinString: ", "
}
I assumed that the .text().trim() part is always present - but it might get more complicated if it has to be more flexible. But there is really no way around it, what you are downloading should be data, not code.
This tells you some ways to avoid using eval:
If you have to, you can evalInSandbox: https://developer.mozilla.org/en-US/Add-ons/Overlay_Extensions/XUL_School/Appendix_C:_Avoid_using_eval_in_Add-ons?redirectlocale=en-US&redirectslug=XUL_School%2FAppendix_C%3A_Avoid_using_eval_in_Add-ons#If_there_is_no_way_around_eval()…
@noitidart: evalInSandbox isn’t really a solution when the point is being able to access DOM elements (the OP is talking about site-specific data extraction).
Ooo thanks for that. Skip my post 
But it’s a good read still if you have time @OP.