New AMO submission rules are blocking updates

See this external issue for more information on the problem, and feel free to rate or weigh in.

Hey, just want you to know, I appreciate and value your work here.

Created by: powrsurg

I just want to say that I'm impressed by your work. I wrote a similar extension to this years ago (though I wanted sites to opt in to updates because I though it could potentially break stuff), but I had to drop it because it would time out every time I submitted new versions to AMO. I'm impressed you were able to include what you had.

@L-a-n-g-o-l-i-e-r-s, @mikini, @gitarra, @Gitoffthelawn, @9Morello, @LeLobster

Hey, just want you to know, I appreciate and value your work here.

Thank you all very much for the support. It means a lot to know that the efforts are appreciated!

@powrsurg

I just want to say [...] I'm impressed [...]. I wrote a similar extension to this years ago (though I wanted sites to opt in to updates because I though it could potentially break stuff) [...].

That's very nice to hear, thank you! After coming up with the concept, I did quite a bit of research to determine if someone had already realized the idea. I do remember your extension, because it was the most interesting one I found. It was definitely well made, and pretty good at what it intended to do.

However, while opt-in works if you control both ends of the line, it doesn't when you don't. Without making it behave like an actual CDN, there was no way to deploy it as a privacy enhancement tool. We approached this from two entirely different angles, and I think your motivation was equally valid.

[...] I had to drop it because it would time out every time I submitted new versions to AMO.

Oh yes, I remember running into the same problems. I ended up changing the file extensions of the resources from .js to .js.dec, just to be able to keep the AMO-assistant from attempting, and then silently failing, to analyze all bundled scripts. That was prior to the policies that sparked this issue.

The automated code linters used to be very unforgiving indeed, and It's sad to hear that this eventually forced you to drop your extension. I'm sure we experienced similar levels of frustration and agony.

In any case, I really like that you dropped by, and hats off for creating Local Load way back in 2010.

Created by: powrsurg

Oh yes, I remember running into the same problems. I ended up changing the file extensions of the resources from .js to .js.dec, just to be able to keep the AMO-assistant from attempting, and then silently failing, to analyze all bundled scripts. That was prior to the policies that sparked this issue.

YOU COULD HAVE JUST RENAMED THE EXTENSION AND IT WOULDN'T HAVE GOTTEN FLAGGED?!?

:: breathes ::

Seriously though, I thought I had tried that and it didn't work. I probably broke something else when I was trying to test it and got my reasons for it failing mistaken. I do remember this work being a pain in the butt to test.

About opt-in having issues, at the time I wrote my extension I was seeing a lot of sites that would simply add jquery in their typical "js" folder that I assumed sites would continue. I considered trying to auto detect compatibility for certain CDNs, but with my inability to get around the timeout issue I eventually had to give up.

Honestly, I hope you're looking in to contribute to the offline spec with the W3C. Back when I started all we had was AppCache, Now we have Service Workers with the ability to cache things (which incidentally, I find funny that I just checked on the Service Worker cookbook just now because of this message and saw that it is itself offline because someone forgot to renew the domain).