LINUX.ORG.RU

Firefox 80

 ,


0

1

Доступен Firefox 80.

  • Появилась возможность назначить Firefox системным просмотрщиком PDF-файлов.
  • Существенно ускорена загрузка и обработка списка вредоносных и проблемных дополнений. Это новшество будет портировано в ESR-выпуск, потому что поддерживать два разных формата «чёрного списка» накладно, а включить изменение в 78-й выпуск (на основе которого формируется текущая ESR-ветка) разработчики не успели из-за обнаружившейся в последний момент неполадки.
  • Включено автоматическое создание резервной копии сохранённых логинов/паролей. Если Firefox обнаружит, что logins.json повреждён, то файл будет восстановлен из резервной копии.
  • Добавлена настройка security.warn_submit_secure_to_insecure, позволяющая отключить предупреждение, выводимое при попытке отправить данные через форму по небезопасному соединению со страницы, открытой по HTTPS.
  • Добавлено больше экспериментальных настроек (для их показа нужно включить browser.preferences.experimental).
  • Теперь срок действия TLS-сертификатов, выданных с 1 сентября 2020 и позже, не может превышать 13 месяцев, а сертификатов, выданных ранее этой даты, не может превышать 825 дней (2 года и 3 месяца). При попытке открыть сайт, использующий сертификат с более длительным сроком действия, будет выдана ошибка. За последние годы максимальный срок действия сертификатов под давлением производителей браузеров последовательно сокращался с 8 до 5, а затем до 3 лет. В 2019 году удостоверяющим центрам удалось отстоять сохранение прежнего срока (3 года), но в начале 2020 года Apple проигнорировала CA/Browser Forum и в одностороннем порядке ввела новое ограничение, после чего к ней присоединились Google и Mozilla.
  • Сокращено количество анимаций для пользователей, у которых в настройках окружения рабочего стола отключены анимации. Например, вместо анимации загрузки страницы будут нарисованы песочные часы.
  • Исправлена ошибка, приводившая к лишнему префиксу «http» в скопированном из адресной строки адресе.
  • Исправлены различные неполадки и падения, возникавшие при использовании экранных чтецов (например, теперь можно зачитывать названия SVG, а также имена меток и описания).
  • JavaScript: добавлена поддержка синтаксиса export * as namespace из ECMAScript 2021.
  • HTTP: директива fullscreen, применённая к <iframe>, не работала, если отсутствовал атрибут allowfullscreen.
  • HTTP: заголовок Pragma теперь игнорируется, если присутствует Cache-Control.
  • Web Animations API: включена поддержка операций компоновки — см. KeyframeEffect.composite и KeyframeEffect.iterationComposite.
  • Media Session API: добавлена поддержка действий seekto (позволяет элементам управления запрашивать поиск определённого временного смещения) и skipad (пропускает текущий рекламный блок, чтобы продолжить воспроизведение основного контента, если такая возможность есть, и если подписка позволяют пропускать рекламу).
  • WebGL: добавлена поддержка расширения KHR_parallel_shader_compile.
  • Window.open() outerHeight и outerWidth больше недоступны веб-содержимому.
  • WebRTC: добавлена поддержка RTX и Transport-cc (улучшает качество звонков при плохом соединении, а также более реалистично оценивает пропускную способность)
  • WebAssembly: разрешены атомарные операции для неразделяемой памяти.
  • Инструменты разработчика:
    • В веб-консоли появилась возможность блокировать и разблокировать сетевые запросы помощью команд :block и :unblock.
    • При назначении класса элементу в Инспекторе пользователю будут предложены варианты автодополнения.
    • Когда отладчик прерывается при возникновении исключения, всплывающая подсказка на панели источника будет содержать значок, раскрывающий трассировку стека.
    • В список запросов сетевого монитора добавлен значок «черепаха», означающий медленное соединение, которое выполняется дольше 500 мс (значение можно менять).
    • В Инспекторе доступна экспериментальная панель, отображающая проблемы кросс-браузерной совместимости.

>>> Примечания к выпуску для разработчиков

>>> Все закрытые в этом выпуске баги

>>> Подробности

★★★★★

Проверено: leave ()
Последнее исправление: Satori (всего исправлений: 3)

Ответ на: комментарий от qbbr

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

Да и как-то проще сказать «это появится в Firefox 85», чем «это появится в Firefox 2020.12.15».

А ещё тогда мы получим ESR с обозначениями вида 2020.12.15.5 и патч-релизы с обозначениями 2020.12.15.0.1. Короче, выходит сложнее, а профита никакого.

MozillaFirefox ★★★★★
() автор топика
Последнее исправление: MozillaFirefox (всего исправлений: 6)
Ответ на: комментарий от Stanson

В соседнем браузере ещё круче:

На странице about:flags появилась опция «Omnibox UI Hide Steady-State URL Path, Query, and Ref» позволяющая отключить отображение элементов пути и параметров запроса в адресной строке, оставив видимым только домен сайта. … По умолчанию скрытие пока активировано только для небольшого процента пользователей. В качестве мотива изменения указывается желание защитить пользователей от фишинга, манипулирующего параметрами в URL.

Обеспечено блокирование небезопасной загрузки (без шифрования) исполняемых файлов и добавлен вывод предупреждений при небезопасной загрузке архивов (zip, iso и т.п.). В следующем выпуске ожидается блокировка архивов и вывод предупреждения для документов (docx, pdf и т.п.). В дальнейшем постепенно планируется полностью прекратить поддержку загрузки файлов без применения шифрования. Блокировка реализована, так как загрузка файлов без шифрования может использоваться для совершения вредоносных действий путём подмены содержимого в процессе MITM-атак.

Также продолжается борьба с HTTP. Разумеется, «ради вашей безопасности». И отменить, конечно же, будет нельзя никак.

anonymous
()
Ответ на: Чудесный релиз от Qui-Gon

осталась похоже основная беда - не работает partial present и соответсвенно аппаратно ускоренный webrender композитор жрет батарею покруче аппаратно неускоренного basic.

Не знаю, как будет с EGL вариантом, но вариант на GLX хоть и давал заметный выигрыш на пустой странице с одной мелкой gif’кой, по сравнению с basic всё равно ел больше ватт.

Там упоминали, что в Mesa уже патч вмержили, так что если не терпится, можно уже пробовать.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

Может я и не прав, но мне кажется что в Firefox что-то лишнего наворотили. egl, dma-buf. Зачем это всё? Если запускать браузер в Wine Staging, там трансляция DXVA2 в VA-API, всё работает.

ZenitharChampion ★★★★★
()
Ответ на: комментарий от MozillaFirefox
  • рядовым пользователям пофиг на версию, целиком и полностью.

  • теже AMD используют нумерацию 20.12 релизов и 20.12.1 для фиксов. выглядит сильно однозначнее и понятнее, чем nvidia 340, 393, 410 итд

Ford_Focus ★★★★★
()
Ответ на: комментарий от ZenitharChampion

Ну так ИМХО предполагается что будущее за Wayland, а там и так EGL обязателен. DMA-BUF - штатный механизм ядра и его отсутствие в системе как-то тоже было бы странно.

Firefox что-то лишнего наворотили

ИМХО наоборот решили обойтись малой кровью не танцуя вокруг libva, как с Chromium.

DXVA2 в VA-API

Ну не в FF же перетаскивать весь код трансляции из Wine. Я, конечно, не специалист в кодовой базе Wine, но догадываюсь, что это помимо собственно адаптера ещё пол-wine надо нести.

SkyMaverick ★★★★★
()
Ответ на: комментарий от SkyMaverick

Ну это Zenitar. Много раз врал в простых вопросах

Так что я бы скептически относился бы к высказыванию

Если запускать браузер в Wine Staging, там трансляция DXVA2 в VA-API, всё работает.

anonymous
()
Ответ на: комментарий от SkyMaverick

> Ну так ИМХО предполагается что будущее за Wayland, а там и так EGL обязателен.

Получается, что используют DMA-BUF и EGL не потому, что это даёт какие-то возможности, а «потому что могут»? Например Chromium, скомпилированный с поддержкой VA-API, работает без всего этого.

> DMA-BUF - штатный механизм ядра и его отсутствие в системе как-то тоже было бы странно.

Лицензия на код DMA-BUF запрещает не-GPL драйверам обращаться к нему. Поэтому драйвер NVIDIA не использует DMA-BUF напрямую, а использует прослойку. Значит, эта фича не заработает на NVIDIA.

>> Firefox что-то лишнего наворотили

> ИМХО наоборот решили обойтись малой кровью не танцуя вокруг libva, как с Chromium.

С Хромиумом вышло кое-что интересное.

Ранние версии ChromeOS базировались на обычном X-сервере, у меня даже есть виртуалка со старой сборкой ChromiumOS, в которую включены проприетарные драйверы NVIDIA и ATi.

Потом в ChromeOS заменили X-сервер на какой-то другой. Тем не менее, в коде браузера Chromium уже была поддержка VA-API в X11.

Энтузиасты нашли этот код, и подправили ./configure, приведя строчки #if $chromeos к виду #if $chromeos || $linux. Всё работало.

>> DXVA2 в VA-API

> Ну не в FF же перетаскивать весь код трансляции из Wine.

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

Кстати, я когда первый раз компилировал Wine Staging (вернее, брал из него отдельные патчи и накладывал на Wine), ему не понравилась моя системная libva. Пишет «хочу библиотеку libva-drm, а у тебя только libva». Я посмотрел и увидел, что mplayer-vaapi работает через libva-glx, а VLC и Wine используют libva-drm.

По-идее, libva-drm может работать как под X11, так и под Wayland. Нет необходимости в «иксах» работать через libva-glx, а в Wayland через libva-egl.

ZenitharChampion ★★★★★
()
Ответ на: комментарий от ZenitharChampion

а «потому что могут»

Наоборот потому что НЕ могут долго и упорно заниматься жёстким сексом с различными глюками различного оборудования и libva. И полагаются на работоспособность механизмов, которые должны в нормальной ситуации работать. Замечу опять же, что это изначально делалось для Wayland, который обязательно требует рабочий EGL, а потом, видимо увидели что специфичного не так уж и много и сделали и для X11 тоже, но тут уже с EGL ситуация несколько спорная.

Значит, эта фича не заработает на NVIDIA.

Кто виноват, что NVIDIA «не такая как все» и не хочет использовать стандартные механизмы.

Всё работало.

Если повезёт с железом, фазой луны и настроением Брина в конкретный день. Часто и откровенно глючит и не работает. Потому что, как правильно замечено, это всё делано и тестировано для хромобуков. А там Intel и некоторые radeon. Остальное - как повезёт.

SkyMaverick ★★★★★
()
Ответ на: комментарий от ZenitharChampion

Энергопотребление замерял?
Я смотрю в патчи в wine-staging/patches/dxva2-Video_Decoder и не вижу, чтобы там было что-то про рендеринг кадров с помощью GPU. Вместо этого я вижу, как там вызывается vaGetImage, чтобы сгрузить данные в память CPU.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

Не замерял - стационарный комп. А патчи обычно размазаны по куче директорий. Я уже не накладываю их отдельно, а просто делаю bash ./wine-staging-%staging_version/patches/patchinstall.sh --all

ZenitharChampion ★★★★★
()
Последнее исправление: ZenitharChampion (всего исправлений: 1)
Ответ на: комментарий от ZenitharChampion

Не замерял - стационарный комп.

Если использование VA-API нужно лишь для галочки, достаточно отдельно запускать vainfo в цикле.

i-rinat ★★★★★
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от cross_platform

Пятиминутка конспирологии

В 2007 году компания ASUS создала EEE PC, который стал очень популярен. Там был Windows/Linux дуалбут. Я считаю, что Microsoft боялась, что кому-то Linux начнёт нравиться сильнее, чем Windows. Актуальной версией Windows была Vista, которая многим не нравилась. Логично, что часть людей присматривалась к Mac и Linux.

В 2008 году NVIDIA сделала VDPAU, а в mplayer приняли патчи, добавляющие поддержку VDPAU. Тогда же ATi реализовала XvBA, и в Cyberlink PowerDVD для Linux появилась его поддержка. Intel реализовала поддержку VA-API. Компания Shattered Desktop добавила поддержку VA-API в mplayer, а также создала враппер XvBA-VAAPI. Adobe добавила поддержку VDPAU и CrystalHD во Flash Player.

И тут Майкрософт посетила идея - не допустить появления аппаратно ускоряемого HD Video в Linux! Вот только в плеерах поддержка уже добавлена, но в браузерах - ещё нет!

До 2016 года можно было смотреть аппаратно ускоренное видео при помощи флеш плеера. Была проблема с «синими людьми» при включенном VDPAU, когда, в очередной версии плеера, разработчики из Adobe перепутали красный и зелёный каналы. Также в одной из версий они стали требовать инструкций SSE2 - пользователи Athlon XP лишились возможности пользоваться VDPAU в браузере (разве что со старой версией флеша). Были даже проблемы с Glibc, в котором внезапно дропнули поддержку флеша. Наконец, сам флеш прекратил поддержку Линукса в версии 11.2.

Всё было хорошо, пока не появился VDPAU.

В 2016, когда YouTube дропнул флеш, в браузерах почему-то не добавляли поддержку ни VDPAU, ни VA-API. Это как с Навальным в госпитале. Сначала же всё правильно делали, кололи атропин. Потом вдруг стали странно себя вести. Также и тут: ну нормально же всё было сначала. Это потом начали что-то мутить воду. То им Gstreamer 0.10 какой-то не такой, а когда вышел Gstreamer 1.x, в котором всё правильно - поддержку Gstreamer внезапно решают удалить. Заменили на ffmpeg, в котором точно должно всё работать, но нет.

Лишь чудом в Chromium нашлась поддержка VA-API, которая «молодой человек, это не для вас написано», а для ChromeOS. Но линуксоиды включили себе эту поддержку, исправив ./configure, что не понравилось гуглу. Поддержку VA-API стали регулярно ломать примерно с 2019 года.

ZenitharChampion ★★★★★
()
Последнее исправление: ZenitharChampion (всего исправлений: 1)
Ответ на: Пятиминутка конспирологии от ZenitharChampion

Нет, тут явно заговор Intel, производителей ноутбуков и программистов, которые писали софтовые реализации кодеков.

Сам посуди. Intel создаёт ноутбучные четырёхядерные процессоры с гипертредингом. Производители ноутбуков создают системы охлаждения, которые предназначены для того, чтобы отводить тепло от процессоров. Разработчики софтовых кодеков оптимизируют их под новые наборы инструкций и особенности новых чипов.

Бум! Проигрывание Youtube загружает максимум одно ядро CPU, причём CPU даже не разгоняется до максимальных скоростей. Бум! Даже полностью загруженное, одно ядро генерирует тепла не больше, чем система охлаждения может отвести пассивно. Бум! Аппаратные декодеры оказываются уже не так уж и нужны. Бум! Под линукс не пишут код с поддержкой аппаратных декодеров.

Заговор.

i-rinat ★★★★★
()

Обож. Vaapi в ютубе работает. Настают последние дни, точно вам говорю.

vasily_pupkin ★★★★★
()
Ответ на: Пятиминутка конспирологии от ZenitharChampion

Ну Microsoft же IBM кинула с OS/2, теперь IBM купила Red Hat и нанесет ответный удар? Договоренности о разделении серверов и десктопов больше не действуют?!

paramon
()
Ответ на: Пятиминутка конспирологии от ZenitharChampion

что не понравилось гуглу. Поддержку VA-API стали регулярно ломать

Гы, ломать что-то у линуксоидов всё равно что доламывать детские игрушки, в которые уже наигрались и забыли. Переходишь на вяленого – и не работает там на хромом vaapi.

papin-aziat ★★★★★
()
Ответ на: комментарий от goingUp

А я то думал, почему на лорчике уже давно нет признаков присутствия машины времени, а ее оказывается увели в мозиллу.

Сдали в лизинг

X-Pilot ★★★★★
()
Ответ на: Пятиминутка конспирологии от ZenitharChampion

Врёт и врёт 🤣 «Чудом нашли» 🤣

Вот видишь, это от Гугла. Со времён около 2012 года

https://chromium.googlesource.com/chromium/src/+/HEAD/docs/linux/hw_video_decode.md

Чудо, это что какой-то анимешник в Fedora нашёл время и начал с жим ковыряться… Да в 2019 году.

И на всём протяжении с того времени (2012 года) оно никогда стабильно не работало. Развалилась через раз с апдейтами, и не только хромиума…

Это неотлаженная связка из навоза и палок.

fornlr ★★★★★
()
Последнее исправление: fornlr (всего исправлений: 2)
Ответ на: комментарий от fornlr

> Чудо, это что какой-то анимешник в Fedora нашёл время и начал с жим ковыряться... Да в 2019 году.

Ещё в 2015 году я установил себе себе ppa saiarcot895/chromium-beta и горя не знал. Всё просто работало на моей ATi Mobility Radeon 4250 и проприетарным драйвером Catalyst 12.4 + xvba-video 0.4.0.

Переколбашивать поддержку VA-API в Chromium начало, когда Google начала контактировать с сообществом по этому вопросу, и обещать официально это включить. В этот момент внезапно что-то начало «отваливаться» и «не работать». С 2019 года примерно, да. До этого 4 года - полёт нормальный.

ZenitharChampion ★★★★★
()
Последнее исправление: ZenitharChampion (всего исправлений: 1)
Ответ на: комментарий от papin-aziat

Переходишь на вяленого – и не работает там на хромом vaapi.

Так если бы было бы две комбинации, а их три: иксы, xWayland, Wayland

fornlr ★★★★★
()
Ответ на: комментарий от ZenitharChampion

Ты этот бред уже говорил. Ты и щас можешь поставить что-то из современного и оно будет работать с гораздо большей верностью даже без всяких васянских реп. Вон в Debian по умолчанию Chromium с VAAPI — может повезти даже.

Так же заморозишь это дело заклинанием «удобрения мамонта окаменись!» и будет работать.

Уж хуже не стало — точно.

fornlr ★★★★★
()
Последнее исправление: fornlr (всего исправлений: 1)
Ответ на: комментарий от ZenitharChampion

когда Google начала контактировать с сообществом по этому вопросу, и обещать официально это включить

Не ври. Не было такого.

fornlr ★★★★★
()
Ответ на: комментарий от fornlr

Было. Первый раз сообщество спросило у Google в 2014 году: https://www.opennet.ru/opennews/art.shtml?num=39242

Второй раз в октябре 2018: https://www.phoronix.com/scan.php?page=news_item&px=Chrome-No-2018-Linux-...

После этого, начались переговоры и уступки. В репозиториях дистрибутивов всё это начало появляться с начала 2019 года:

Google Chrome GPU acceleration under Linux/NVIDIA binary drivers
В арчик Chromium с VA-API завезли
Про ubuntu, chrome, youtube и аппаратное ускорение

Хотя опять же повторюсь, что до этого момента такая сборка была уже 5 лет, только отдельным пакетом. И я бы не назвал saiarcot895 ppa - «васянским». Во времена Ubuntu 14.04 он был не менее популярным, чем Oibaf PPA.

И примерно тогда же начались жалобы что «всё сломалось», хотя до этого момента 5 лет работало.

ZenitharChampion ★★★★★
()
Последнее исправление: ZenitharChampion (всего исправлений: 1)
Ответ на: комментарий от ZenitharChampion

Ты ж обиженная свжшка на нвидию , че постишь редирект на забаненного персонажа тобой же ? Ты какой то не ликвид копии торва

anonymous
()
Ответ на: комментарий от ZenitharChampion

После этого, начались переговоры и уступки. В репозиториях дистрибутивов всё это начало появляться с начала 2019 года

Не ври. Позиция Google на протяжении восьми лет не менялась

видеосистема в линуксах — ночной кошмар, вот вам документация, исходники открыты, делайте что хотите в своих дистрибутивах. В апстримном Chromium этого не будет

Ничего не менялось. Только в дистрибутивах нашлись силы это сделать, а раньше просто балду пинали.

fornlr ★★★★★
()
Последнее исправление: fornlr (всего исправлений: 1)
Ответ на: комментарий от fornlr

При этом они сами же «запилили» VA-API под X11 :-) «Патч от анимешника из Fedora» заменяет 5 строк вида #if $chromeos на #if $chromeos || $linux

Собственно вот: https://build.opensuse.org/package/view_file/network:chromium/chromium/chromi...

ZenitharChampion ★★★★★
()
Последнее исправление: ZenitharChampion (всего исправлений: 1)
Ответ на: комментарий от ZenitharChampion

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

anonymous
()
Ответ на: комментарий от ZenitharChampion

Ты че не можешь зайти в chrome://flags сам ? Ты решил им нарисовать что это их заслуга ? Ты откуда такой васявер?

anonymous
()
Ответ на: комментарий от fornlr

Ты заявляешь, что якобы Google говорила «для нас это тёмный лес, мы в это лезть не будем», а акселлерацию запилил разработчик из Fedora в 2019 году.

ZenitharChampion ★★★★★
()
Ответ на: комментарий от ZenitharChampion

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

anonymous
()
Ответ на: комментарий от ZenitharChampion

Ту-тук. В голове что-то есть?

Гугл заявляла вот опция скомпиляйте так и так и будет условно работать с глюками и багами.

Анимешник из Fedora включил это в Fedora. И на него столько багов посыпалось. Что потом для Nvidia вырубили.

Да и по Intel был вон баг мощный. А он «у меня на AMD всё работает 🤷‍♂️».

В чём противоречие? Он пионер в пионерском дистрибутиве включил полуэксперементальную фичу. Имеет право.

fornlr ★★★★★
()
Последнее исправление: fornlr (всего исправлений: 1)
Ответ на: комментарий от fornlr

https://bazaar.launchpad.net/~saiarcot895/chromium-browser/chromium-browser.p...

Патчик прямиком из 2015 года. Правит 5 строк, разрешая включать VA-API не только для ChromeOS, но и для Linux. Фичу сделала сама Google. И на её ChromeBook всё работает на GPU от Intel.

Когда я устанавливал браузер Chromium из «васяно-репо», как ты выразился, ~saiarcot895/chromium-dev, всё работало. И не только у меня: на ЛОРе многие пользовались такой фичей, как VA-API в Chromium. И единственной проблемой было только «чё-то проц всё равно перегружен» «а ты h264ify включил?» «нет, сейчас попробую. О, теперь работает».

А когда фичу перенесли из PPA в официальные репозитории дистров, а Google начала анонсировать VA-API чуть ли не в апстримном бинарном Chrome... Вот тогда «внезапно» начались глюки. Что касается работы VA-API на NVIDIA - сорри, не тестил.

ZenitharChampion ★★★★★
()
Ответ на: комментарий от ZenitharChampion

Может, дело в том, что раньше фичей пользовались десятки людей, а теперь - тысячи, и просто выявлять баги стали активнее. Что-то с трудом верится, что VA-API стали намеренно ломать.

ZenitharChampion ★★★★★
()
Ответ на: комментарий от ZenitharChampion

А когда фичу перенесли из PPA в официальные репозитории дистров, а Google начала анонсировать VA-API чуть ли не в апстримном бинарном Chrome…

Не ври. Гуглу это всё не сдалось.

Вот был сделан побочный продукт на основе того, что ChromeOS была на иксах и VAAPI (второе осталось), ну собственно вот. Что есть, то есть.

fornlr ★★★★★
()
Последнее исправление: fornlr (всего исправлений: 3)
Ответ на: комментарий от ZenitharChampion

раньше фичей пользовались десятки людей, а теперь - тысячи

Да, конечно. Ибо эту фичу включили в Fedora, Arch, Debian по умолчанию. Предсказуемо отхватили кучу багов мейнтенеры сразу.

fornlr ★★★★★
()

в google play оставил отзыв «firefox must die». не от злого или обиды просто грусть какая то накатила.

anonymous
()
Ответ на: комментарий от Mischutka

Нет. Я так понимаю новый FF и стал последним пинком в пользу решения пилить llvm-фронт под Эльбрус (т.к. Rust).

SkyMaverick ★★★★★
()
Ответ на: комментарий от annerleen

давно пора. Я несколько лет назад как перешел с Мозиллы на Оперу, когда Мозилла стала переходить на Квантум движок

bonta ★★★★★
()
Ответ на: комментарий от bonta

давно пора. Я несколько лет назад как перешел с Мозиллы на Оперу, когда Мозилла стала переходить на Квантум движка

Я наоборот. После 15 лет (ничего себе) использования Opera перешёл на Firefox.

Наконец-то Firefox перестал вызывать отвращение тормозами.

Причины две: плохая поддержка линуксов и китайская реклама вот со всеми этими алиэкспрессами

fornlr ★★★★★
()
Последнее исправление: fornlr (всего исправлений: 1)

В Fedora-31 приехал firefox-80, таки да, работает vaapi на иксах, прикольно чё, но переходить на иксы уже желания нет.

papin-aziat ★★★★★
()
Ответ на: комментарий от Radjah

Да, только как это реализовать и когда это будет возможно. Как только это сделают - это будет божественно

Promusik ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.