MozillaZine

9/10/2004version Dead Extensions list

Talk about add-ons and extension development.
GrailKnight

User avatar
 
Posts: 2359
Joined: January 5th, 2004, 5:40 am
Location: Pennsylvania, USA

Post Posted September 11th, 2004, 4:53 am

Hello Cusser,

I was always under the impression that extension updates followed Firefox advancement.

That is what I have gotten from reading the extension developers posts over time.

Upgrade Firefox = upgrade extensions.

Please let me know if that is not the case as previous posts and replys by the extension developers have led me to believe this.

Thanks

GrailKnight
"There is nothing more deceptive than an obvious fact". - Sherlock Holmes

BenBasson
Moderator

User avatar
 
Posts: 13671
Joined: February 13th, 2004, 5:49 am
Location: London, UK

Post Posted September 11th, 2004, 6:02 pm

My gripe isn't so much with people's expectations that extensions should work, it's that they're going about it entirely the wrong way. If there's a problem with maxVersion checking when updating or installing, it needs to be fixed.

In order to test the Extension Update system, the version number has been bumped from 0.9+ to 0.10 in recent nightlies.

Putting the maxVersion at anything other than 0.10 isn't helping Firefox development and is, quite frankly, not going to help the users of your extensions either, since you are making a false guarantee of compatibility, and you do not know that they will think to upgrade... chances are that many people will use extensions with a maxVersion of 1.2 or 5.0 (common values) which may break or cause dataloss in 1.1... you just don't know.

Anyway...

If a 0.9 compatible extension that you have installed is listed on update.mozilla.org as 1.0PR compatible and is the same version number (e.g. My Extension v1.5), the extension should not be disabled.

If a 1.0PR compatible version of your installed extension exists but is a newer version (e.g. My Extesion v1.6)... you should be offered an upgrade by Firefox instead of the extension being disabled.

If you are installing a 1.0PR compatible extension and it refuses to install, you need to file a bug linking to the XPI.

If either of these things are failing, you need to file a bug ASAP, so that Ben can get this sorted!

rue
 
Posts: 673
Joined: June 10th, 2003, 2:20 pm

Post Posted September 12th, 2004, 10:35 am

Cusser:
Here's my thoughts -- purely dev-side:
.
Implicit: it's easily possible for an extension to remain indefinitely compatible. Firefox "compatibility" is assessed by the app in an unintelligent fashion, and the compatibility-index is incremented fairly frequently.
.
Explicit: update.rdf allows for remote patching of the maxVersion, to distant-future indexes. Update.rdf is also highly mutable, asserting its changes immediately to update-requests. Devs. can "disable" or "re-enable" their extensions remotely, in this fashion.
.
Conclusion: the old system, where users test + report incompatibility back to devs, is still accessible. And it is compatible with <a href="http://update.mozilla.org/extensions/?application=firefox">u.m.o.</a>'s policy, since the initial manifest maxVersion can be overridden at install-time, remotely. It's more powerful, more flexible and -- when configured proper -- puts complete control directly in the extension-dev's hands.

BenBasson
Moderator

User avatar
 
Posts: 13671
Joined: February 13th, 2004, 5:49 am
Location: London, UK

Post Posted September 12th, 2004, 10:35 am

The problem with that policy is that it relies on the extension developer to be present indefinitely or for someone to be prepared to deal with all incompatible extensions when problems arise. With the maxVersion system, the author (or someone else) is required to check for compatibility, but this is no good at all if version numbers higher than the next imminent release are used. The principle is that the original author must update the extension, or it simply isn't installable... if they are not present, then someone else must do it for them.

If we're looking to expand the market share of Firefox, waiting for the user to see an extension "break" before acting is totally unreasonable. As I said, it could cause dataloss, including profile corruption. The answer to so many problems on this forum has been "have you tried a new profile?", and it's one of the reasons why people label most extensions as "buggy", whether they've tried them or not. We cannot take market share if we require users to make new profiles or use safe mode to manually troubleshoot for every small issue.

You're correct that a remote manifest gives control, but that's only if: 1) The extension is part of update.mozilla.org or uses a custom rdf and 2) Someone hasn't installed a version with a higher maxVersion than should be needed.

Currently if the maxVersion is 1.2, 3, 5, 10 or 100, Firefox will let you install, because it only looks at u.m.o. if the initial maxVersion fails, and in all of these scenarios, it will not.

rue
 
Posts: 673
Joined: June 10th, 2003, 2:20 pm

Post Posted September 12th, 2004, 10:35 am

Cusser:
That "problem" is still present when an absent-dev's extension is disabled. To borrow your words: <blockquote>The version-disabling system relies on the extension developers to be present indefinitely or for someone to be prepared to deal with all such incompatible extensions</blockquote> To the end-user, once extended functionality is depended-on, any sudden loss would be rightly called problem. You're simply trading potential loss (via conflict) for certain loss (as disabled).

bkarel
 
Posts: 42
Joined: January 24th, 2004, 8:16 am
Location: wonkothesane

Post Posted September 12th, 2004, 10:35 am

I opened a bug about this back in mid-July, and wrote about the subject at some length:
http://bugzilla.mozilla.org/show_bug.cgi?id=251148

Keep in mind that Ben had not added remote update.rdf checking at the time when that was written.

A few key points:
<ul>
<li> How many times have you actually seen *extensions* break due to API changes in Firefox? I can only think of one: Adblock, which was broken due to nsIContentPolicy changes on May 15, and was fixed in less than a week. Themes are another issue -- it seems like themes are much more likely to break than extensions, since the UI is being twiddled with quite a bit from release to release. On the other hand, a required maxVersion has caused and is causing problems. Something to keep in mind.
</li><li> The number of changes that will be checked in along with a version-increment is vanishingly small. Thus, it logically follows that when extensions break due to API changes, they will do so at some point during the stream of nightlies that lie between releases.
</li><li> Since UMO doesn't let extension authors upload updated versions of their extensions (yet), each point release has and will cause massive amounts of essentially unnecessary work for the understaffed UMO crew. This overload slows down the updating of the few extensions that actually need updated version, precisely when download rates are highest and damage is maximized.
</li><li> Since extensions break during the nightly period and not on the exact build that gets its version incremented, there should be sufficient time for users to report *actual problems* and then either have the extension author update the extension, add a maxVersion, or remove the extension from UMO (the UMO crew can remove/disable the extension in the absence of an active developer).
</li><li> If an abandoned extension breaks and nobody is willing to rescue it, it's probably not that popular or useful in the first place, and isn't going to be a great loss when it falls by the wayside. The whole point of open-source is that if something is useful, it'll be kept afloat.
</li><li> Even with maxVersion, UMO can still serve dataloss-causing broken extensions, it'll just be the nightly users you'll be alienating. The vibes I've been getting from Wolf and alanjstr seems to be "screw 'em." Unsavory, perhaps, but understandable if not for the doublethink.</li>
</ul>

BenBasson
Moderator

User avatar
 
Posts: 13671
Joined: February 13th, 2004, 5:49 am
Location: London, UK

Post Posted September 12th, 2004, 10:35 am

wonkothesane wrote:How many times have you actually seen *extensions* break due to API changes in Firefox? I can only think of one: Adblock, which was broken due to nsIContentPolicy changes on May 15, and was fixed in less than a week. Themes are another issue -- it seems like themes are much more likely to break than extensions, since the UI is being twiddled with quite a bit from release to release. On the other hand, a required maxVersion has caused and is causing problems. Something to keep in mind.

I think until the Firefox API becomes more solid, the maxVersion principle is a good idea. You're right that themes are more likely to break, but extensions that offer extensive functionality can easily stop a profile from loading up.

wonkothesane wrote:Since UMO doesn't let extension authors upload updated versions of their extensions (yet), each point release has and will cause massive amounts of essentially unnecessary work for the understaffed UMO crew. This overload slows down the updating of the few extensions that actually need updated version, precisely when download rates are highest and damage is maximized.

I agree. Hopefully someone is working on this, as it's greatly needed. Using a custom RDF source is also possible though, if you wish to be in control yourself.

wonkothesane wrote:Since extensions break during the nightly period and not on the exact build that gets its version incremented, there should be sufficient time for users to report *actual problems* and then either have the extension author update the extension, add a maxVersion, or remove the extension from UMO (the UMO crew can remove/disable the extension in the absence of an active developer).

Agreed, I'd love to see extension and theme developers offered an official release candidate a couple of weeks before the release. I hope Mozilla.org or Ben will do this after 1.0, since we need that time to ensure that everything is going to work for the release. Getting milestones out is important, but if only half of the usual extensions are ready, it's a problem (as rue states).

wonkothesane wrote:If an abandoned extension breaks and nobody is willing to rescue it, it's probably not that popular or useful in the first place, and isn't going to be a great loss when it falls by the wayside. The whole point of open-source is that if something is useful, it'll be kept afloat.

I strongly agree with this. This is why I support maxVersion checking and using legitimate maxVersions... if enough people use an extension, someone like Rowne, MonkeeSage, TheOneKEA or myself can repackage it (as we have done in the past).

wonkothesane wrote:Even with maxVersion, UMO can still serve dataloss-causing broken extensions, it'll just be the nightly users you'll be alienating. The vibes I've been getting from Wolf and alanjstr seems to be "screw 'em." Unsavory, perhaps, but understandable if not for the doublethink.

I've been using nightlies for a bit recently, and I simply bumped the version number down in my user.js, and I'll continue to do it in the future. Without disrespecting nightly users, I do not thouroughly test my extensions on nightlies and I do not (necessarily) support nightly builds in any way, so I will not claim that my extensions work with them unless I reverse this policy. You're technically correct that extensions on UMO can break things, but they're less likely to, since the majority of users will be milestone users, and the extensions have to go through a few basic checks before being approved.

I think what we need is an extension that lets you install things with a lower maxVersion, and allows you to enable extensions that were disabled due to their lower maxVersion. As an extension, people have to think about what they're doing and what the risks are before they use it, whereas if it were built in by default (as it used to be), people would expect extensions to "just work". Shall I do this?

sasquatch
 
Posts: 6022
Joined: November 25th, 2003, 8:56 am

Post Posted September 13th, 2004, 6:53 am

Sensemann and Grailknight, it would have helped if you said what version of Firebird you were running.

sasquatch
 
Posts: 6022
Joined: November 25th, 2003, 8:56 am

Post Posted September 13th, 2004, 6:58 am

Cusser wrote:...
I've been using nightlies for a bit recently, and I simply bumped the version number down in my user.js, and I'll continue to do it in the future. Without disrespecting nightly users, I do not thouroughly test my extensions on nightlies and I do not (necessarily) support nightly builds in any way, so I will not claim that my extensions work with them unless I reverse this policy. You're technically correct that extensions on UMO can break things, but they're less likely to, since the majority of users will be milestone users, and the extensions have to go through a few basic checks before being approved.
...


This thread is about nightly builds, hence the name.

It is as much about finding out if others are having the same problem as it is about letting extension developers know there is a problem.

Thanks.

sasquatch
 
Posts: 6022
Joined: November 25th, 2003, 8:56 am

Post Posted September 13th, 2004, 7:22 am

Cusser wrote:The problem with that policy is that it relies on the extension developer to be present indefinitely or for someone to be prepared to deal with all incompatible extensions when problems arise. With the maxVersion system, the author (or someone else) is required to check for compatibility, but this is no good at all if version numbers higher than the next imminent release are used. The principle is that the original author must update the extension, or it simply isn't installable... if they are not present, then someone else must do it for them.

If we're looking to expand the market share of Firefox, waiting for the user to see an extension "break" before acting is totally unreasonable. As I said, it could cause dataloss, including profile corruption....


Isn't "profile corruption" the name of the game with Firefox? That is almost ALWAYS the first thing people say to check in any of the forums when someone is having trouble. Sad, but true.

rue
 
Posts: 673
Joined: June 10th, 2003, 2:20 pm

Post Posted September 13th, 2004, 9:01 am

whoa- all the posts dated 10:35 (above) are in reverse-order.
.
note.

©dn

User avatar
 
Posts: 683
Joined: April 20th, 2003, 1:53 pm
Location: GB

Post Posted September 13th, 2004, 2:09 pm

Funny, the times are 5:35pm [UTC] here.

ieremiou

User avatar
 
Posts: 637
Joined: July 20th, 2004, 3:21 pm
Location: Brooklyn, NYC

Post Posted September 13th, 2004, 2:19 pm

12:35 PM [EST]

There reason is in the header... >>> Because of the switch to a new host, some post dates were incorrect. We have rolled back all post dates to this morning to help solve the problem.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050922 Firefox/1.6a1 - Build ID: 2005092210

sasquatch
 
Posts: 6022
Joined: November 25th, 2003, 8:56 am

Post Posted September 16th, 2004, 11:53 am

Well, Session Saver and Bookmark Links Checker seem to be the only ones left which are still not working.

Rowne Mastaile

User avatar
 
Posts: 1434
Joined: December 21st, 2003, 3:05 pm
Location: Housed in a swirling neosma of scintillating thought and turgid ideas.

Post Posted September 16th, 2004, 12:23 pm

Just to deviate back to an earlier point, for a moment. The only reason I use 5.0 as a maxVersion is because there are often changes within the internal version number that I simply don't want to deal with. With my current extensions they're all repackaged as 5.0 and I haven't seen one of the disablements others have complained about and as you can see from my InfoLister output-page, I have the internal version set to 1.0PR.

Yet I do agree with Cusser on a lot of points, the only reason I do this is because I like nightlies and I don't want the hassle of dealing with these things. It's because I agree with him that I pulled a lot of the extensions I did have in my cache that might've caused confusion. I still use them myself but I'm no longer sharing them publically.

However, I'd be more than happy to set them all to 0.10 again and perhaps share my local mirror again (if nobody had any problems with 0.10set extensions) if there were an extension similar to that which Cusser has described. I think it would be helpful indeed. An extension that allows one to keep their Firefox version but to oh, say "Treat all extension installations as if they had a maxVersion of 5.0." That way, I fcould take those risks by myself.

So this is a stance I wholly support, is that even possible? It's something I'm curious about, that.

Moving along...

~ Sasquatch (Session Saver): SessionSaver 'Buttons! Edition' is working fine for me. It's the version I tinkered with and repackaged. It has a couple of buttons and stuff. Nothing really special. It can be obtained here [install].

~ Sasquatch (Profile Corruption): The profile I'm using right now is from a late 0.8 nightly, it hasn't corrupted once. I porked it twice by manually editing Chrome files but I made backups before doing so so it was all okay anyway. The only other problem I had was that an older EMButtons created dualitous Dom Inspector entries which I quickly found and deleted. I don't think profile corruption is the name of the game *Cough.* with Firefox at all. In honesty, I think it would take an action of abject foolishness to break a Firefox profile. Especially since the additions post 0.9.2. Sad but true, that.

Return to Extension Development


Who is online

Users browsing this forum: No registered users and 2 guests