Возможно я ошибаюсь, но на примере плагина Roboform (для хранения паролей) вижу, что как только выходит новая версия браузера, старый плагин Roboform становится с ним не совместим.
Это особенность плагина Roboform или все плагины устаревают с обновлениями FF. Если это так, то почему выбрана такая кривая модель, с коротким сроком жизни плагина. А если автор перестанет поддерживать плагин? Обновился FF - и все, плагин в мусорку?

во-первых ты путаешь плагины с дополнениями.
во-вторых - да, часто с выходом новой версии [firefox] изменяется набор существующих АПИ: какие-то добавляются, какие-то изменяются, какие-то удаляются. Это может повлияеть на то, что дополнение перестаёт быть совместимым.
Но бывает и выход версий, в которых практически не трогают АПИ и там проблем совместимости дополнений не появляется.
С новой политикой частого выхода мажорных версий - реализуют (если ещё не реализовали) систему внутреннего информирования авторов дополнений о том, что АПИ используемые в их дополнениях были изменены.
Т.к. сейчас в каждом дополнении цифрой прописывается номера версии браузеров с которыми оно совместимо - то получается, что часто дополнение перестаёт работать с новой версией браузера не потому, что оно не может с ним работать, а потому, что в списке поддерживаемых версий браузеров нет новой вышедшей версии браузера.
Поэтому есть и более далекоидущие планы изменения системы обновления: мофо хотят сделать так, что дополнения, которые остались совместимыми с новой версией браузера (например, какие-то бета-тестеры поставили новую версию браузера, какое-то дополнение и отключили проверку совместимости версий дополнений в браузере) планируется перекраивать на стороне АМО подменяя в файлах запись о совместимости с новой версией браузера.
Уже было создано дополнение (test pilot, кажется) которое через менеджер дополнений позволяет отправлять информацию в мофо (которую они перенаправляют авторам этих дополнений) о том работает ли дополнение или нет (или работает но частично и т.п.).
И я не уверен, но кажется они планировали делать проверку по АПИ: т.е. с новой версией появились какие-то изменения в списке АПИ - дополнения хостящиеся на АМО проверяются на наличие использования этих АПИ в коде - если используются изменённые АПИ - авторы уведомляются, если нет - то дополнение помечается как совместимое с новой версией браузера.

> но кажется они планировали делать проверку по АПИ
Это надо было сделать до изменения системы обновлений на более частую. Фактически, многие расширения могут полноценно работать, и при этом помечаются как несовместимые; другие же просто ловят мелкие баги, но тем не менее тоже продолжают работать.

Я лично считаю такую недоработку (когда при обновлении у пользователя вдруг отваливаются расширения) каноничным былинным отказом, и вина тут полностью на разработчиках браузера.

Я тоже считаю это виной разработчиков браузера. У меня есть простенькие плагины к другим системам, к тому же QIP, которые годами работают без изменений. И их авторы давно умерли.
А тут разработчикам плагинов нужно, блин, следить за струей и обновлять плагины по мере обновления FF.
Может не нужно так часто и кардинально менять API? Может нужно дать пользователю возможность на свой страх и риск юзать прежние плагины?

Hate Forest пишет

Это надо было сделать до изменения системы обновлений на более частую. Фактически, многие расширения могут полноценно работать, и при этом помечаются как несовместимые; другие же просто ловят мелкие баги, но тем не менее тоже продолжают работать.

ну у них в компании нет великих стратегов и до такого они попросту не додумались.

но на самом деле - если у расширения живой разработчик - то он всё быстро поправит (всем разработчикам вроде как отправляются уведомления всегда о грядущем выходе новой версии браузера, так что вина тут скорее не разработчиков браузера в том что они не успели ещё создать вышеописанную систему, а разработчиков расширений в том, что они мертвы.

fixin пишет

И их авторы давно умерли.

значит вина авторов.

fixin пишет

Может не нужно так часто и кардинально менять API?

они меняют не без причин

fixin пишет

Может нужно дать пользователю возможность на свой страх и риск юзать прежние плагины?

такая возможность пользователю дана: в about:config ключ extensions.checkCompatibility

fixin пишет

Может нужно дать пользователю возможность на свой страх и риск юзать прежние плагины?

Кто ж вам мешает? Отключайте проверку совместимости и нет проблем. Даже расширение специальное для этого придумали, чтобы в конфиг руками не лазить. Один раз установили и пользуетесь до конца..... кхм... ну вы поняли. )))

iDev.Pi пишет

nightly tester tools

не-а - Add-on Compatibility Reporter (https://addons.mozilla.org/ru/firefox/addon/add-on-compatibility-reporter/)

03-10-2011 14:38:20
В смысле, nightly tester tools устарело слегка. Add-on Compatibility Reporter поновее будет.

ок. за инфу по отключению совместимости спасибо. Но методика контроля совместимости какая-то не правильная, так и знайте. это мое имхо.

fixin пишет

так и знайте

Ага, спасибо. Только нам от этого знания ни жарко, ни холодно, т.к. все на этом форуме присутствующие имеют отношение к этой методике не больше, чем вы сами.

ну должны же в FF быть заинтересованы в качестве продукта? Хотя ладно, я не в курсе их системы менеджмента качества. Так, брякнул на всякий случай, вдруг дойдет до Мозиллы, что они немножко не правы.

> так что вина тут скорее не разработчиков браузера в том что они не успели ещё создать вышеописанную систему, а разработчиков расширений в том, что они мертвы.
Вот я например перешел с XP на 7, и что, мне теперь надо, что бы M$ разослала всем своим разработчикам заявки, пересоберите мол свои программы, что бы они работали? Речь же идет о тех расширениях, которые не работают только из-за контроля версий. Или таких нет?

Речь же идет о тех расширениях, которые не работают только из-за контроля версий. Или таких нет?

Hate Forest Если дело только в цифорке, то эту проблемку прекрасно пока решает упомянутое выше расширение Add-on Compatibility Reporter :angel:

Традиционные дополнения могут делать в Firefox практически всё что угодно, в отличие от Chrome. Из-за этого в Firefox практически невозможно вносить изменения, не ломая какое-либо из традиционных дополнений.
Если дополнение содержит бинарные компоненты, то пляска с install.rdf не поможет.

Boris недавно отвечал по этому поводу:

> I could be wrong, but this seems unduly pessimistic. The overwhelming
> majority of the work I did as a MoCo employee did not break add-on
> compatibility or change the user experience. Here's an incomplete list
> of things that (it seems to me) we could keep putting in minor releases:

> * Improvements to existing Web features

Maybe.  It depends on the improvement.

> * Entirely new Web features

No.  This breaks addon compat.  If the addon uses inline attribute event
handlers, you can't add new properties on Element, Document, Node,
without possibly causing name collisions.  If it uses them on HTML
elements, you can't add properties on HTMLElement either.

> * Speed improvements

As long as they don't change APIs.  Often they do.  Or are you not
worrying about binary addons here?  Note that binary addons are some of
the things causing grief for large deployments.  Oh, and for users of
all the various virus scanner toolbars, etc.  Was Google toolbar pure
JS, by the way?

> * Additions to exposed extension-JS interfaces
> * Entirely new exposed extension-JS interfaces

Why is this limited to JS?  It certainly simplifies things, but ignores
where a lot of the addon compat pain is.

> The only things I can think of that we _couldn't_ do in a minor release
> are break the duck type of an extension-JS interface, modify browser XUL
> in a way that would break an <overlay> (this would probably break
> visible UI anyway) and intrusive UI changes (like changing from the
> traditional menu bar to the unified menu).

Or any removal of web-facing functionality.  Or really any addition of
web-facing functionality.

Addons use web technologies.  That's the selling point.  It also means
that our web-facing API is part of our addon compat story.

Again, this is limiting to pure-JS addons, of course.

One other comment: even for pure-JS addons, ctypes exists.  So that
makes all exported symbols part of our addon API. :(

> But then, I think we should officially deprecate and
> phase out support for binary add-ons anyway.

Sure.  Once we get there, we can have a totally different conversation!

Of course the race is on between that and SDK-based addons.
-Boris

> Если дело только в цифорке, то эту проблемку прекрасно пока решает упомянутое выше расширение Add-on Compatibility Reporter
Это расширение по идее нацелено на тестеров новых версий, "Note: Recommended for alpha and beta users only!". Зачем простому пользователю что то знать об этом, если действительно вопрос только в циферке? За примером далеко идти не надо.

Вот я например перешел с XP на 7, и что, мне теперь надо, что бы M$ разослала всем своим разработчикам заявки, пересоберите мол свои программы, что бы они работали?

Да.

Парочка живых примеров несознательных разработчиков.

starforce.jpg
21.jpg

fixin

почему выбрана такая кривая модель, с коротким сроком жизни плагина

Потому что компании Mozilla нет дела до проблем пользователей, купивших коммерческий продукт, работающий с броузером и имеющий соответственный механизм интеграции в него через расширение.

А если автор перестанет поддерживать плагин?

Значит пользователь останется без продукта и будет мучиться.

Обновился FF - и все, плагин в мусорку?

Да, в том случае если авторы коммерческой программы быстренько не выпустят обновлённую версию, то именно так и есть — в мусорку, а заодно туда же отправятся и деньги, потраченные на коммерческий продукт, если его использование без броузера не имеет смысла или сильно неудобно.


iDev.Pi

ну у них в компании нет великих стратегов и до такого они попросту не додумались.

Судя по всему, «великих стратегов» там хватает, а вот толковых планировщиков нету. Потому что это было очевидно ещё год назад.


fixin пишет:

    И их авторы давно умерли.

значит вина авторов.

Вы ещё умысел тут найдите. «Как умер, я не давала такого распоряже…» ((с) к/ф «Служебный роман»).

fixin

ну должны же в FF быть заинтересованы в качестве продукта?

Они больше заинтересованы в скорости выхода новых версий, чтобы напихать туда побольше новшеств, многие из которых более чем сомнительны.

Так, брякнул на всякий случай, вдруг дойдет до Мозиллы, что они немножко не правы.

А им уже много кто брякал, потихонечку вроде стало доходить, но медленно.

banbot

Если дополнение содержит бинарные компоненты, то пляска с install.rdf не поможет.

Вот именно. А большинство расширений, обеспечивающих интеграцию с броузером коммерческих продуктов, именно их как раз чаще всего и содержат. Что, в Mozilla об этом не знали? Или знали, но плевать хотели?

Я об этом уже писал здесь и здесь:

Возможно всё дело в том, что их модель разработки не предполагает такой быстрой смены версий, и сейчас эти конторы продолжают работать по инерции. Конечно, они должны будут как-то перестраиваться под новые реалии, если хотят сохранить за собой рынок (ибо свободных решений продолжает появляться всё больше, и что-то мне подсказывает, что у них проблем со скоростью смены дополнительных примочек к другим свободным продуктам будет поменьше), но, как мне кажется, и компании Mozilla явно стоит что-то предпринять по этому поводу, чтобы как-то эти компании заинтересовать. Пока что, как видим, данный вопрос компанию Mozilla никак не заботит, и я опасаюсь, что ответная реакция не заставит себя долго ждать — некоторые особо «упоротые» могут начать целенаправленно игнорировать Firefox. И всё бы ничего, только в конечном итоге больше всех в результате такой вероятной «войнушки» наверняка проиграют пользователи… :(

Tiger.711

Славно бы было.

Для нас — возможно. А вот производители сторонних продуктов могут уйти, к примеру, на Хром, перетащив за собой часть бывших пользователей Firefox. И, IMHO, в отличие от нас, Mozilla могла бы об этом побеспокоиться… если, конечно, компании не наплевать на возможную потерю части целевой аудитории. Если наплевать — тогда, разумеется, и беспокоиться не о чем. :cool:

И вот ещё, по этой же теме: http://forum.mozilla-russia.org/viewtop … 88#p507088.

MySh пишет

Вы ещё умысел тут найдите. «Как умер, я не давала такого распоряже…» ((с) к/ф «Служебный роман»).

Здесь "умер" употреблено в иносказательном контексте: потерял интерес, некогда, стало всё равно, и т.п. (© КО) Умысла действительно нет, но и смысла ориентироваться на такое расширение - тоже.

MySh пишет

Они больше заинтересованы в скорости выхода новых версий

Я думаю, всё-таки в скорости доведения до пользователей того, что несут в себе эти версии; сами по себе версии как цифры/релизы - дело очень пятое.

MySh пишет

чтобы напихать туда побольше новшеств, многие из которых более чем сомнительны

А вот тут нельзя ли поподробнее? Я таковые припомнить затрудняюсь со времен 4-й версии. Именно такие новшества, за которыми бы стояли существенные изменения в API, чреватые несовместимостью дополнений.

MySh пишет

А большинство расширений, обеспечивающих интеграцию с броузером коммерческих продуктов, именно их как раз чаще всего и содержат.

Начнем с того, что я на своей памяти не припомню ни одного случая, чтобы пользователь использовал эти расширения - на них либо не обращают внимания, и терпят, как что-то ненужное и доставшееся в в нагрузку к основному функционалу продукта, либо отключают, либо, если позволяют знания и навыки, сносят. Я, конечно, понимаю, что моя личная статистика не особенно репрезентативна, но всё же определенные выводы относительно нужности таких расширений сделать можно. Дополнительный аргумент в пользу сомнительной надобности в таких расширениях - функциональность, появившиеяся в 8-й версии, и позволяющая сразу же отключать такие вот довески в нагрузку.
Далее. Бинарные XPCOM-компоненты в расширениях, на самом деле, не особенно часто встречаются - а именно в их случае фатальна смена версии релиза. Бинарные компоненты для js-ctypes, бинарные интерфейсы к скриптовым реализациям компонентов - все они смену версии переносят нормально. И поэтому повторюсь (я уже об этом писал ранее) - я считаю, что если расширение несовместимо с текущей версией FF, то в этом заслуга только и исключительно автора.

> Парочка живых примеров несознательных разработчиков.
Первый пример - StarForce, богомерзкая программа, которая использует наверное рекордное количество недокументированных API. Тем более это даже не программа, а драйвер.

Второй - игра, насколько я знаю там есть StarForce, в любом случае только сообщается о возможной нестабильной работе, запустить приложение можно.

hydrolizer

Я думаю, всё-таки в скорости доведения до пользователей того, что несут в себе эти версии; сами по себе версии как цифры/релизы - дело очень пятое.

IMHO, одно другому не противоречит.

А вот тут нельзя ли поподробнее? Я таковые припомнить затрудняюсь со времен 4-й версии. Именно такие новшества, за которыми бы стояли существенные изменения в API, чреватые несовместимостью дополнений.

Поскольку я не разработчик, за API говорить не готов. Я могу сказать, что конкретно мне не нравится и что у меня поломалось, а вы уж как специалист сами выводы делайте. Я вполне допускаю, что многие проблемы возникли из-за моей собственной криворукости и неспособности лихо с ними разобраться, слегка поковырявшись в коде, только я ещё раз напомню — я не разработчик. Как и процентов девяносто пользователей этого форума, и , наверное, ещё больше среди всех пользователей Firefox. Итак, для начала нововведения, которые мне не нравятся (справедливости ради стоит отметить, что большая часть из них так или иначе обходится или хотя бы не слишком сильно мешает, иначе в принципе не стал бы обновляться):

  • Панорама. Вот сто лет она мне не нужна. Да, я ей просто не пользуюсь — но ресурсы-то она потребляет, а также служит потенциальным источником несовместимости.
  • Анимация открытия и закрытия вкладок — ужасно тормозит; хорошо, что можно отключить, плохо, что только через about:config.
  • Синхронизация — тут, в принципе, та же история, что с Панорамой.
  • Новый менеджер дополнений — тормозит, но это полбеды. Хуже то, что теперь дополнения либо обновляются по-тихому автоматически, либо только вручную, а промежуточного варианта с уведомлениями нет. Правда, эту проблему более-менее успешно решает костыль Addon Update Checker, без него было тяжко, а с ним ещё жить можно.
  • Объясните, пожалуйста, зачем всё-таки надо было соединять вместе закладки и историю? Теперь, если что-то случилось, пропадает сразу и то и то. Правда, я уже научен, но всё равно неприятно же последние посещённые адреса терять!
  • Кнопка обновить по умолчанию расположена IMHO по-дурацки. Прав vladmir — попса же какая-то! Ладно хоть исправляется легко, но перед людьми же, когда им ставишь первый раз или обновляешь, неудобно («ага, c Хрома слизали!» — и не возразишь ведь).
  • Срок хранения истории теперь настроить нельзя — вроде и мелочь, а неприятно.
  • Выкинули значок RSS из адресной строки. С одной стороны вроде и правильно, а с другой теперь быстро не узнаешь, есть на сайте RSS-поток или нет. Опять же, хорошо, что есть расширения.
  • Недавнее нововведение — скрытие http:// в адресной строке. Опять же, отключается только через about:config.
  • Как я слышал, в новых версиях кнопка «вперёд» по истории переходов исчезнет — останется только «назад» (вместо кнопки будет что-то другое). Ну вот зачем это надо делать?

Но это ладно — косметические нововведения, большинство из которых так или иначе можно обойти. Но вот то, что отвалились многие нужные расширения(BBCopy, ArchView, Memory Meter, причём последнее отвалилось буквально недавно) и минимум одна кнопка для Custom Buttons — очень досадно!

я на своей памяти не припомню ни одного случая, чтобы пользователь использовал эти расширения - на них либо не обращают внимания, и терпят, как что-то ненужное и доставшееся в в нагрузку к основному функционалу продукта, либо отключают, либо, если позволяют знания и навыки, сносят.

Зато я таких знаю. По крайней мере одного человека, которому очень не хватает панели от AVG.

определенные выводы относительно нужности таких расширений сделать можно

А вы почитайте форум, где люди пишут о проблемах с Касперским, Lingvo и Промтом — за которые они, между прочим, заплатили денег (многие, по крайней мере) — и тогда уже делайте выводы.

Бинарные XPCOM-компоненты в расширениях, на самом деле, не особенно часто встречаются - а именно в их случае фатальна смена версии релиза. Бинарные компоненты для js-ctypes, бинарные интерфейсы к скриптовым реализациям компонентов - все они смену версии переносят нормально.

Я этого не знаю и знать не хочу. Если я купил продукт, я хочу, чтобы он работал. Точка.

если расширение несовместимо с текущей версией FF, то в этом заслуга только и исключительно автора.

Если всё так просто и легко, почему автор не может просто взять и исправить это? Может быть, он этого не знает? А почему? Может быть, потому, что разработчики из Mozilla в своей бешеной гонке за новшествами просто не побеспокоились узнать его мнение или хотя бы достаточно ясно и наглядно оповестить обо всех нюансах?
В общем, как бы там ни было, но, стараясь глядеть на ситуацию объективно, я не могу не отметить, что вся эта история с гонкой версий выглядит, пусть, может быть, и отчасти, но всё же не хорошо. Я чувствую себя в чём-то кинутым, и мне это не нравится. Хотя не могу не признать, что и польза в быстром развитии и внедрении поддержки новых стандартов есть. Вот только аккуратнее всё это надо было делать.

Я этого не знаю и знать не хочу. Если я купил продукт, я хочу, чтобы он работал. Точка.

Вы форумом не ошиблись? ;)

А по теме: производителей расширений явно вынуждают использовать какой-нибудь AMO.

MySh пишет

Я этого не знаю и знать не хочу. Если я купил продукт, я хочу, чтобы он работал. Точка.

Вы ЗАПЛАТИЛИ за открытый и бесплатный браузер????:dumb:
ну так кто ж вам доктор?:tongue2:

MySh пишет

Может быть, он этого не знает? А почему? Может быть, потому, что разработчики из Mozilla в своей бешеной гонке за новшествами просто не побеспокоились узнать его мнение или хотя бы достаточно ясно и наглядно оповестить обо всех нюансах?

Если автор зарегистрирован на АМО - то всё он знает, я же выше давал ссылку на свой же постинг, в котором описан процесс оповещения. И я не вижу ничего сверх в том, чтобы раз в полтора месяца уделить полчаса-час времени своему выложенному на АМО творению - больше, как правило, не требуется, т.к. при существующей схеме релизов изменения, произошедшие в новом релизе, сравнительно невелики, и не требуют больших трудов для адаптации расширения (если вообще требуют) - это, собственно, и было одной из целей схемы быстрых релизов. И поскольку мало у кого из авторов на АМО ситуация с расширениями такова, как, например, у этого (или у этого), то никаких сверх-усилий для поддержания своих расширений в актуальном состоянии не требуется.

Тут вчера ген.дир. МоФо, товарищ Митчелл Бэйкер написала блогопост, как раз по тематике заданного здесь вопроса.
В нём она заявила о планах уйти от модели, когда дополнение считается несовместимым с новой версией браузера до тех пор, пока не будет доказано обратное. Этот слишком консервативный подход не стыкуется с новой политикой частых релизов мажорных версий браузера. В связи с этим, все дополнения от Мозиллы уже перешли на новую модель, а сейчас ведётся аналогичная работа по вводу подобной системы и для остальных дополнений.
Вот страница проекта, можете следить за развитием проекта там.
Как я и предполагал - теперь АМО будет отправлять информацию о (не)совместимости дополнений при обновлении браузера. Информация о работоспособности дополнений будет прежде всего собираться через Addon Compatibility Reporter, который можно установить отсюда и помогать пополнять Мозилле базу данных о работоспособности дополнений.

Кстати, а то, что непроверенные новые версии уже существующих расширений доступны в разделе версий расширения - это всегда так было?

И кстати, благодаря Addon SDK можно создавать джетпаки (расширения не требующие перезагрузки), которые планируется сделать самообновляемыми. Правда метод их обновления пока ещё разрабатывается (либо запихнуть сорс-код в xpi-файл, что утяжелит его и плохо скажется для мобильных юзеров, либо запихнуть сорс-код на АМО отдельно от xpi-файла, что увеличит загрузку АМО и потребует приделаывания некоторых примочек, либо встроить часть теперь будут автоматически пересобиратсья на стороне АМО в случае выхода новой версии браузера, либо встроить части Addon SDK прямо в браузер и сборка будет происходить на стороне юзера).

05-10-2011 05:10:36

hydrolizer пишет

это всегда так было?

да.

Так. Продолжим.

MySh пишет

Я могу сказать, что конкретно мне не нравится и что у меня поломалось

Это всё понятно, но вопрос был а) о новшествах, внесенных после 4-й версии (4-я версия - это очень отдельный случай); б) новшествах, чреватых несовместимостью дополнений. Всё, что вы перечислили, либо появилось в версии 4, либо никак на совместимость не влияет (например, потому, что абсолютно новая функциональность - как та же панорама - в принципе не может влиять на старую), либо и то, и другое вместе. Разговор же у нас о несовместимости расширений, а не о том, почему в новых версиях всё так плохо :)
Если кому интересно - вот что в версиях после 4-й ветки могло повлиять на совместимость расширений:

скрытый текст
Firefox 5:

  • In order to comply with the HTML5 specification, support for the UTF-7 and UTF-32 character sets has been removed.
  • WebGL no longer loads textures from domains other than the originating domain, as a security measure. HTTP access control support should be coming sometime in the future to make this possible more securely.
  • The selection object's modify() method has been changed so that the "word" selection granularity no longer includes trailing spaces; this makes it more consistent across platforms and matches the behavior of WebKit's implementation.
  • The window.setTimeout() method now clamps to send no more than one timeout per second in inactive tabs. In addition, it now clamps nested timeouts to the smallest value allowed by the HTML5 specification: 4 ms (instead of the 10 ms it used to clamp to).
  • Similarly, the window.setInterval() method now clamps to no more than one interval per second in inactive tabs.
  • The Blob and, by extension, the File objects' slice() method has been removed and replaced with a new, proposed syntax that makes it more consistent with Array.slice() and String.slice() methods in JavaScript. This method is named mozSlice() for now.
  • The Node.prefix property is now read only, as required by the DOM specification.
  • Regular expressions are no longer callable as if they were functions; this change has been made in concert with the WebKit team to ensure compatibility (see WebKit bug 28285. This feature had existed for a long time but was never documented (at least, not here on MDC).
  • Firefox no longer sends the Keep-Alive HTTP header; we weren't formatting it correctly, and it was redundant since we were also sending the Connection: or Proxy-Connection: header with the value "keep-alive" anyway.
  • The nsIAppStartup2 and nsIAppStartup_MOZILLA_2_0 interfaces have been merged into the nsIAppStartup interface.
  • The nsIDocShell_MOZILLA_2_0_BRANCH interface has been merged into the nsIDocShell interface.
  • The nsIFocusManager_MOZILLA_2_0_BRANCH interface has been merged into the nsIFocusManager interface.
  • The nsIHTMLEditor_MOZILLA_2_0_BRANCH interface has been merged into the nsIHTMLEditor interface.
  • The following interfaces were implementation details that are no longer needed:

    • nsICiter (see bug 633066 )
    • nsIDOM3Document (see bug 639849 )
    • nsIFIXptrEvaluator
    • nsISelectElement (see bug 619996 )

Firefox 6:

  • <form> elements' text <input> fields no longer support the XUL maxwidth property; this was never intentional, and is in violation of the HTML specification. You should instead use the size attribute to set the maximum width of input fields.
  • The azimuth CSS property is no longer supported, as we have removed what little code we had for the aural media group. It was never significantly implemented, so it made more sense to remove the crufty implementation for the time being rather than try to patch it up.
    In the past, the :hover pseudoclass was not applied to class selectors when in quirks mode; for example, .someclass:hover did not work. This quirk has been removed.
  • navigator.securityPolicy, which has returned an empty string for a long time, has been removed outright.
  • The document.height and document.width have been removed. bug 585877
  • The DocumentType object's entities and notations properties, which were never implemented and always returned null, have been removed, since they've been removed from the specification anyway.
  • The DOMConfiguration interface and the document.domConfig property that used it have both been removed; they were never supported and have since been removed from the DOM specification.
  • The FileReader interface's abort() method now throws an exception when used if no file read is in progress.
  • The document.strictErrorChecking property has been removed, since it was never implemented and was removed from the DOM specification.
  • The window.top property is now properly read only.
  • DOM views, which we never documented, have been removed. This was a bit of implementation detail that was unnecessarily complicating things, so we got rid of it. If you notice this change, you're probably doing something wrong.
  • The mozResponseArrayBuffer property of the XMLHttpRequest object has been replaced with the responseType and response properties.
  • For security reasons, data: and javascript: URIs no longer inherit the security context of the current page when the user enters them in the location bar; instead, a new, empty, security context is created. This means that script loaded by entering javascript: URIs in the location bar no longer has access to DOM methods and the like, for example. These URIs continue to work as before when used by script, however.
  • Support for microsummaries has been removed; these were never widely used, were not very discoverable, and continuing to support them was making improvements to the Places (bookmark and history) architecture difficult.
  • The following interfaces were implementation details that are no longer needed:

    • nsIDOMDocumentEvent (see bug 655517 )
    • nsIDOMDocumentTraversal (see bug 655514 )
    • nsIDOMDocumentRange (see bug 655513 )
    • IWeaveCrypto (see bug 651596 )
    • nsIDOM3DocumentEvent (see bug 481863 )
    • nsIDOMAbstractView
    • nsILiveTitleNotificationSubject
    • nsIPlugin (see bug 637253 )
    • nsIPluginInstance (see bug 637253 )
    • nsIHTMLEditRules (see bug 633750 )
    • nsIXSLTProcessorObsolete (see bug 649534 )

Firefox 7:

  • The HTMLHeadElement profile property has been removed, this property has been deprecated since Gecko 2.0.
  • The HTMLImageElement x and y properties have been removed.
  • Support for the non-standard globalCompositeOperation operations clear and over has been removed.
  • The File interface's non-standard methods getAsBinary(), getAsDataURL(), and getAsText() have been removed as well as the non-standard properties fileName and fileSize.
  • document.createEntityReference has been removed. It was never properly implemented and is not implemented in most other browsers.
  • document.normalizeDocument has been removed. Use Node.normalize instead.
  • DOMTokenList.item now returns undefined if the index is out of bounds, previously it returned null.
  • Node.getFeature has been removed.
  • The HTMLInsElement and HTMLDelElement interfaces have been removed, since the <ins> and <del> elements actually use the HTMLModElement interface.
  • window.resizeTo, window.resizeBy, window.moveTo , and window.moveBy no longer apply to the main window.
  • The Function.arity property has been removed; use Function.length instead.
  • The nsIMarkupDocumentViewer_MOZILLA_2_0_BRANCH interface has been merged into the nsIMarkupDocumentViewer interface.
  • The nsIDOMWindow2 interface has been merged into the nsIDOMWindow interface.
  • The nsIDOMWindow_2_0_BRANCH interface has been merged into the nsIDOMWindowInternal interface.
  • nsINavHistoryObserver methods with URI parameters now require a GUID as well.
  • The nsISHistory_2_0_BRANCH interface has been merged into the nsISHistory interface.
  • The nsIMemoryReporter interface has been substantially changed; if you use it, you will need to make some adjustments to your code.
  • The nsIThreadInternal2 interface has been merged into the nsIThreadInternal interface.
  • The following interfaces were implementation details that are no longer needed:

    • nsIDOM3Attr
    • nsIDOM3Node
    • nsIDOM3TypeInfo
    • nsIDOM3Text
    • nsIDOMDocumentStyle
    • nsIDOMNSDocument
    • nsIDOMNSFeatureFactory
    • nsIDOMNSHTMLDocument
    • nsIDOMNSHTMLFormElement
    • nsIDOMNSHTMLHRElement
    • nsIDOMNSHTMLTextAreaElement

  • The following interfaces were removed as part of the removal of the ActiveX embedding API:

    • DITestScriptHelper
    • DWebBrowserEvents
    • DWebBrowserEvents2
    • IDispatch
    • IMozControlBridge
    • IMozPluginHostCtrl
    • IWebBrowser
    • IWebBrowser2
    • IWebBrowserApp
    • IXMLDocument
    • IXMLElement
    • IXMLElementCollection
    • IXMLError
    • nsIActiveXSecurityPolicy
    • nsIDispatchSupport
    • nsIMozAxPlugin
    • nsIScriptEventHandler
    • nsIScriptEventManager

Firefox 8 (draft):

  • The HTMLIsIndexElement constructor has been removed. No elements have implemented this interface since before Firefox 4.
  • document.getSelection() now returns the same Selection object as window.getSelection(), instead of stringifying it.
  • window.navigator.taintEnabled has been removed; it has not been supported in many years.
  • The deflate-stream extension to WebSockets has been disabled; it has been deprecated, and was breaking compatibility with some sites.
  • ISO8601DateUtils.jsm code module has been removed. The parse() method now supports ISO 8601 dates and should be used instead.
  • The ownerWindow attribute has been removed from the nsIAccessNode interface.
  • The nsIDOMStorageWindow interface has been merged into the nsIDOMWindow interface.
  • All members of the nsIDOMWindowInternal interface have been moved into the nsIDOMWindow interface. The interface itself (with no members) remains available for compatibility until Firefox 9.
  • The nsIMemoryReporter KIND_MAPPED attribute has been deprecated in favor of KIND_NONHEAP.
  • The nsISelection2 interface has been merged into the nsISelectionPrivate interface.
  • The nsISelection3 interface has been merged into the nsISelection interface.
  • The nsISessionStartup attribute state is now a jsval instead of a string, for performance reasons.
  • The nsIDocShell attribute isActive is now false for minimized windows.
  • The following interfaces were implementation details that are no longer needed:

    • nsITimelineService
    • nsIDOMHTMLIsIndexElement


Мое личное резюме по этому длинному списку: практически никаких революционных изменений, все перечисленное в основном - текущая работа по приведению внутреннего хозяйства к спецификациям, удаление давно неиспользуемых, или чреватых дырами в безопасности методов/свойств/объектов, и т.п. - дело, по моему скромному, нужное и полезное.

MySh пишет

А вы почитайте форум, где люди пишут о проблемах с Касперским, Lingvo и Промтом — за которые они, между прочим, заплатили денег (многие, по крайней мере) — и тогда уже делайте выводы.

Так пусть за работоспособность этих творений и отвечают сами разработчики творений - обеспечивают совместимость, отслеживают обновление продукта, который они бесплатно используют для создания доп. функционала к своему основному продукту. FF-то здесь при чем? В противном случае, извините, получится ситуация "блохи рулят собакой".

MySh пишет

Я этого не знаю и знать не хочу.

Вас об этом знать никто не заставляет - об этом обязаны знать разработчики продукта. И все претензии - к ним.

MySh пишет

Если я купил продукт, я хочу, чтобы он работал. Точка.

Вы купили продукт, да. Но не Firefox вместе с ним в одной коробке. Который вполне себе работает - не работает продукт, использующий FF. Как вы думаете, кто тут виноват?

hydrolizer

Вас об этом знать никто не заставляет - об этом обязаны знать разработчики продукта. И все претензии - к ним.

Это всё понятно. Но факт в том, что при старом темпе обновлений сторонние разработчики коммерческих расширений как-то поспевали за новыми версиями, а сейчас часто — нет. Вот я хочу понять, почему. Они что, внезапно стали глупее? Ленивее? В чём же дело?

[firefox] вполне себе работает - не работает продукт, использующий FF. Как вы думаете, кто тут виноват?

А вот интересный момент. Дело в том, что с недавнего времени номер версии Firefox не играет роли, по крайней мере с точки зрения маркетинга, но при этом фактически он определяет, будет ли работать расширение, использующее модули с двоичным кодом. Поэтому разработчики честно пишут, что их продукт совместим с Firefox — и, что характерно, не врут ведь! Но только забывают уточнить, с какой именно версией совместим, как и то, что через несколько недель после обновления он снова отвалится, и никто ничего не будет с этим делать, или будет, но не сразу — как раз к новой версии Firefox поспеют… И если пользователь всего этого не знает, то со всей очевидностью следует вывод, что он значит и виноват — не изучил ситуацию, не спланировал возможные последствия, не провёл экспертизу и не учёл множества очевидных любому квалифицированному разработчику нюансов и т. д. Вот только беда в том, что пользователи вряд ли будут готовы с этим согласиться, а вместо этого будут продолжать время от времени появляться вот такие отзывы: ссылка, ссылка, ссылка, ссылка, и ещё одна ссылка, и много их ещё будет, ой много… Можно говорить, что это троллинг, проплаченный пиар, заговор адептов Хрома и Оперы, вот только не на пустом же месте такие настроения появляются?

Эта проблема теперь у нас как бородатый анекдот... :(