Tak to już jest, kiedy decyduje się używać bety czegokolwiek. Jako pocieszenie warto dodać, że pomijając detekcje zgodności z wersjami (wystarczy rozpakować dodatek bo xpi to zip i zmienić max version w jednym xmlu) znaczna część pluginów teoretycznie niezgodnych instaluje się i funkcjonuje poprawnie. Poza tym po wyjściu stabilnej wersji firefoxa do momentu gdy dany plugin staje się w pełni kompatybilny nie upływa wiele wody w rzece. Więc nie ma co narzekać...

No to masz rozszerzenie Nightly Tester Tools, które załatwia większość tego rodzaju problemów addons.mozilla.org/pl/firefox/addon/6543

Samemu można spróbować "poprawić" niektóre dodatki ;-) Wystarczy je ściągnąć, zapisać na dysk i zajrzeć do środka [to pliki ZIP]. Środku szukamy pliku install.rdf, a w nim taga em:targetApplication i jego podwęzła em:maxVersion, w którym wpisujemy 3.0.0.* i wszystko powinno działać. Chciałem zamieścić "źródło" zmiany, ale engine komentarzowy nie pozwala na wstawianie znaków mniejszości i większości ;-)

@Mikmach - a czy niby ma się różnić beta od final, że mają nie działać dodatki? To kwestia systemowego rozwiązania.

@prwimmer: Hackowanie to duże słowo
Gdy Ty tworzyłeś kompendium wiedzy o HTMLu, niektórzy tak w grach sobie dodawali $ :)

Wtedy to było o tyle trudniejsze, że sejwy to binaria, a nie zzipowany XML

Patrys dobrze mówi, ja zmieniam w install.rdf max wersje przeglądarki i działa większość. Często autorzy nie aktualizują bo nie są przetestowane, albo nie mają czasu/przestali rozwijać projekt. (wystarczy rozpakować plik .xpi (to zwykły zip), zmienić w pliku install.rdf maksymalną wersję (ładny xml, wiec nic trudnego), zapakować i zainstalować)

@Gość - jeśli są dla tych "co wiedzą", to nie powinny być wystawiane publicznie, dla milionów ludzi.
Poza tym jakie to ma znaczenie, skoro w wersji finalnej dodatki także się posypią, bo niemal zawsze tak jest. Ja cały czas mówię o generalnej zasadzie zgodności w dół, a nie różnicach między alfą, betą i final.

Jak już ktoś napisał o tym czy dodatek jest kompatybilny czy nie decydują autorzy dodatków. Są tacy, którzy wpisują od razu wysoką wersje w nadziei, że zadziała, inni postępują defensywnie i dopiero po stwierdzeniu, że działa wypuszczają update. Rozumiem, że zakładając, że jest API, które się nie zmienia można oczekiwać, że przy nowej wersji wszystko powinno nadal działać, ale często problem sprawiają sytuacje, które nie są wyspecyfikowne i w nowej wersji działają inaczej. Są też dodatki, które korzystają z niepublicznych interfejsów i przy takich nie można nawet zakładać, że z nową wersją zadziałają. Beta Firefox'a nie służy do normalnej pracy - dlatego nie powinno się nawet oczekiwać, że autorzy będą dostosowywać swoje dodatki do bet. (np. nie słyszałem o firmach tworzących plug-iny do bet Visual Studio). Jeśli zaczniemy testować bety z kilkudziesięcioma dodatkami, z których jeden czy dwa będą się sypać to takie testowanie jest bezcelowe.

Takiego mechanizmu żaden programista (przy zdrowych zmysłach) nie zapewni z podanych przeze mnie wyżej przyczyn. (przykład: Windows - supportowane jest API z czasów Windows 3.0 - zaś aplikacje pisane na ten system nie są automatycznie uznawane za kompatybilne z nową wersją - ten przykład chyba najlepiej ilustruje co chciałem wyrazić).

Zgoda. Przy małych wersjach (2.0.0.x ale nie 1.5- 2.0 czy 2- 3) nie powinno coś takiego występować... Tylko nie pamiętam kiedy ostatnio taka sytuacja miała miejsce (używam około 40 rozszerzeń - trudno byłoby to przeoczyć). Jeśli dodatek rzeczywiście przy takich zmianach nie działa to na 90% jest to wina autora (w sensie rzeczywiście nie działa, a nie że jest wyłączony bo autor ustawił mu taką a nie inną obsługiwaną wersje, wtedy FF zachowuje się bardzo przytomnie wyłączając takie rozszerzenie) - gdyby przy małych wersjach API FF rzeczywiście psuł kompatybilność z dodatkami to już dawno byśmy masowe słyszeli skargi autorów dodatków.

Pawle, z jednej strony masz grupę programistów rozwijających Firefoksa (czy jakikolwiek inny opensource'owy projekt udostępniajacy dość skomplikowane API), a z drugiej - grupki programistów (a częściej - pojedyncze osoby) tworzące wtyczki w oparciu o dokumentację API.

Za zapewnienie zgodności wtyczki odpowiada autor wtyczki. W sytuacji, gdy są to ludzie, którzy udostępniają wtyczki nieodpłatnie, to jasne, że nie zawsze mają czas zająć się tym natychmiast po pojawieniu się nowej wersji kodu. Nie ma technicznie możliwości, żeby zrobił to ktoś inny za nich. Ba, czasami projekty padają, bo brak chętnych do opieki nad danym kawałkiem kodu.

Używając porównania, które może zrozumiesz łatwiej: to, co zaproponowałeś, zabrzmiało tak, jakbyś się poskarżył, że strony pisane w HTML 3.2 z rozszerzeniami specyficznymi dla przegladarek nie walidują się jako HTML 4.01.

Pamiętasz te wszystkie strony z niezamkniętymi elementami <p>, z elementami <marquee> czy atrybutami MARGINTOP i MARGINLEFT? Z hackowanymi arkuszami stylów, bo IE i NN miały różne pomysły w kwestii tego, jak należy implementować CSS czy DOM? Przejście na nowe wersje przegladarek wymagało rezygnacji z co starszych rozwiązań. Z punktu widzenia autorów stron to wyglądało tak, jakby twórcy HTML 4.01 nie zapewnili zgodności z 3.2. Tymczasem niektóre rozwiązanie już w 3.2 miały status "deprecated"...

A tak naprawdę problem wygląda nieco inaczej - trochę tak, jak z wersjami Flasha. Parę lat temu, jak przez dłuższy czas na rynku był Flash bodajże 4.0, po zmianie numerka wersji okazało się, że kod na niektórych stronach sprawdzał, że wersja jest inna niż 4 (np. 5) ...i żądał zainstalowania czwórki. Wówczas wina leżała po stronie twórców stron, którzy nie przewidzieli zmiany wersji na wyższą (żądali konkretnie 4.0 zamiast = 4.0).

W przypadku wtyczek do FF, jest trochę podobnie - autorzy wtyczek deklarują zgodność z wersjami od 1.0 do np. 2.0.0.12. Pojawienie się wersji 2.0.0.13 powoduje, że dana wtyczka jest oznaczana jako niezgodna. W przypadku wersji 2.0.0.x jest to stosunkowo mało prawdopodobny scenariusz, bo API jest na tyle stałe, że twórcy wtyczek mogą z góry założyć pewien zapas (i co najwyżej zaraz po ukazaniu się wersji szybko przetestować), albo po prostu pilnują wydań nowych wersji i dostosowują kod wtyczki jeszcze przed oficjalnym wypuszczeniem nowej wersji FF (np. ScrapBook instaluje co chwila różne poprawki - mam wrażenie, że polegają one m.in. na podbijaniu widełek, tj. zmianie z wyprzedzeniem numerka najpóźniejszej obsługiwanej wersji...)

Jednak w przypadku wersji beta scenariusz wygląda inaczej. Twórcy wtyczek nie mogą mieć pewności, że kod jest stabilny i że API działa poprawnie. Wszystko jest dobiero testowane. Dlatego aktualizacja wtyczek dla wersji beta wymaga o wiele więcej zachodu. W tym wypadku spora część twórców wtyczek po prostu odpuszcza sobie aktualizację na bieżąco, wiedząc, że mogą nie zdążyć. I nie można ich za to winić.

Znowu, używając bardziej webmasterskiego porównania - to tak, jakbyś żądał od twórców witryn, żeby już teraz, pomimo braku zatwierdzonej specyfikacji, zaczynali pisać kod w HTML 5 - i przerabiali go za każdym razem, gdy grupie zajmujacej się tą wersją przyjdzie do głowy zmienić roboczą specyfikację jakiegoś detalu...

@Godric - dzięki za obszerne wyjaśnienie. Mnie martwi tylko, że jest jakaś przyrodzona wrażliwość Firefoksa i wtyczek na zmiany, że przy małym upgradzie potrafi się to sypać. Brakuje mi właśnie odporności, większej "wytrzymałości" kodu. To mnie dziwi, stąd moje uwagi.

Extensions.checkCompatibility i wszystko ;)

@Gość - problem jest znacznie szerszy, bo zjawisko występuje w upgrade'ach typu 0.01, a nie tylko w betach. O tym pisałem.