LINUX.ORG.RU

Firefox 103

 ,


1

1

Доступен Firefox 103.

  • Linux:
    • Исправлены проблемы с производительностью WebGL при использовании DMA-Buf в сочетании с проприетарным драйвером NVIDIA.
    • Исправлена ошибка, из-за которой были доступны не все принтеры.
    • В дополнение к появившейся в прошлом выпуске возможности собрать Firefox на Wayland-системах, где Mesa собрана без поддержки X11, теперь можно собрать его на системах, где Mesa собрана с поддержкой X11.
    • Исправлена работа функции «Показать загруженный файл в папке», которая работала некорректно (в открывшейся папке файл не был выбран) в Firefox, поставляемом в виде snap-пакета.
  • FreeBSD: декодирование видео вынесено в отдельный процесс (в сборках под Linux это было реализовано полтора года назад), поскольку теперь это является необходимым условием для работы VA-API.
  • Повышена производительность при использовании высокочастотных мониторов (120 Гц и выше).
  • Добавлена поддержка контроллеров Oculus Quest2.
  • В стандартном режиме защиты от отслеживания включён механизм Total Cookie Protection. До этого веб-сайт мог прочитать свою куку, если она образовалась при посещении других сайтов, как third-party кука. Например, если пользователь посещал веб-сайт example.com, на котором установлен виджет VKontakte, то он получал куку VK, а когда затем он логинился на vk.com, то VK понимал, что тот пользователь, который заходил на example.com и этот залогинившийся пользователь — одно лицо. Это позволяло эффективно отслеживать перемещения пользователей между сайтами. Теперь же, все third-party куки хранятся в привязке к домену, на котором они установлены, и условный vk.com уже не сможет прочитать свои куки, установленные в ходе посещения других ресурсов.
  • Окно «Картинка в картинке» обзавелось кнопкой управления субтитрами (включение/отключение, изменение размера). Кроме того, показ в этом режиме субтитров и титров теперь поддерживается на ресурсах youtube-no-cookie.com, Nebula и BBC.co.uk.
  • Реализована подсветка обязательных для заполнения полей в PDF-файлах.
  • Неразрывные пробелы больше не удаляются при копировании текста из форм.
  • Кнопки на панели вкладок теперь доступны с клавиатуры (аналогично тому, как это уже давно реализовано для других панелей).
  • Блокировка автовоспроизведения теперь распространяется и на Web Audio.
  • Исправлена ошибка, из-за которой сохраняемые файлы иногда лишались расширения.
  • Исправлен медленный запуск браузера, вызванный обработкой содержимого в локальном хранилище. Эффект будет особенно заметен, если в качестве системного накопителя используется жёсткий диск, а локальное хранилище имеет большой объём.
  • Налажена работа HTTP/3 после жёсткой (Ctrl+F5) перезагрузки страницы.
  • Запрещена поддержка подписей SHA-1 в импортированных корневых сертификатах.
  • macOS:
    • Повышена отзывчивость браузера при высокой загрузке процессора.
    • Буфер обмена больше не очищается при закрытии браузера.
  • Windows:
    • Инсталлятор теперь создаёт ярлык не только на рабочем столе и в меню «Пуск», но и на панели задач.
    • Системная настройка «Увеличить размер текста» теперь увеличивает не только текст в интерфейсе браузера, но и сами элементы интерфейса, а также веб-содержимое.
  • HTTP: заголовок Digest теперь поддерживает SHA-384 и SHA-512.
  • MathML: прекращена поддержка устаревших атрибутов scriptminsize и scriptsizemultiplier.
  • CSS:
  • JavaScript: Error, EvalError, RangeError, ReferenceError, SyntaxError, TypeError, URIError и AggregateError теперь могут быть сериализованы с использованием алгоритма структурированного клонирования. Сериализованные свойства включают в себя name, message, cause, fileName, lineNumber и columnNumber. Для AggregateError сериализуются свойства message, name, cause и errors.
  • API:
    • ReadableStream, WritableStream и TransformStream теперь являются переносимыми объектами.
    • caches, CacheStorage и Cache теперь требуют безопасный контекст (HTTPS) и не определены, если используются в небезопасном контексте.
    • window.location.reload() и window.history.go(0) больше не блокируются, если они вызваны напрямую из обработчика событий изменения размера окна (это был костыль, предотвращающий возникавшие проблемы с интерфейсом, но он вызывал и проблемы с совместимостью на мобильных устройствах).

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

>>> Все исправленные в этом выпуске ошибки

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

★★★★★

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

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

Ох же ж. Это какая-то жесть. У человека и так HiDPI экран, а он ещё xrandr --scale 1.5x1.5 делает. Зачем? Этот --scale ведь в другую сторону работает.

Если для монитора, который система видит как 1920x1080 монитор сделать --scale 1.5, то система станет его видеть как 2880x1620 монитор. Как бы всё правильно, разрешение отмасштабировалось в полтора раза по обоим измерениям. Но вряд ли это желаемое поведение для обладателя 4k монитора.

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

Спасибо. Я это знаю.

Перешёл вообще на текущую, не esr. Поживём на ней, посмотрим. Раньше же жил, хоть и с SeaMonkey вторым браузером, теперь с ЯБ вторым, но необходимость есть в ЯБ жизненная.

Mamluk
()

Спасибо! Вернулся я с esr версий, на текущую и теперь она будет обновляться.

Хорошо постарались. Вроде бы всё пофиксили, из-за чего я убегал на esr.

Успехов!

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

Я вот давно подозреваю что те у кого «шрифты корявые» и «глаза болят в иксах, а в вяленом не болят», или наоборот, просто не понимают что и как они настраивают этими scale на своих HiDPI мониторах.

Происходит оно от непонимания что такое DPI в иксах и как оно рассчитывается, отсутствия этого понятия в wayland, упёртости его разрабов в кратное масштабирование и непонимание юзеров как в вяленых DE и WM реализуется масштабирование некратное.

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

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

Ну вот так. В иксах DPI рассчитывается динамически от физических размеров экрана полученных через EDID или указанных в конфиге и желаемого разрешения, если его конечно принудительно не указать. А в вяленом фиксированное значение 96 DPI. Причём в иксах может быть разный DPI для разных экранов одновременно, а в вяленом глобально прибито одно значение для всего.

Ну и дробное масштабирование прикольно делается: скажем 1.5 будет делаться так — сначала увеличим в два раза, отрендерим векторы и шрифты, а потом композитором отмасштабируем вниз чтобы стало 1.5 уже «запечённый» битмап. И похерим соответственно шрифты и контуры.

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

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

Задача не такая глупая, как может показаться. Например, в Libreoffice Writer нужно, чтобы размер страницы A4 на экране совпадал по размерам с реальным листом A4.

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

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

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

Ну и к тому же работа с динамическим DPI уже давно сломана в GTK, там тоже прибитое гвоздями 96, что бы ты там в иксах не выставлял и что бы там они сами себе не высчитали. По понятным причинам сейчас это никто уже и не будет исправлять. Так что в иксах почти у всех тоже в конфиге или в настройках DE выставлено фиксированное 96 DPI, иначе GTKшный софт начинает колбасить и он выглядит неконсистентно с qtшным например.

Поэтому забей, эта битва проиграна.

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

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

А у меня нормально выглядит. Даже вживую подстраивается: https://imgur.com/a/QAM0SMS. Приложение на Qt5 не подхватывает изменения, но если перезапустить, то размеры шрифтов тоже меняются.

Фиксированный DPI=96 выставлен в иксах, насколько я понимаю. И это даже не меняется в настройках иксов. Недавно как раз эту проблему пытались решить, протащив размеры от физических экранов до экранов иксов, выпятив реальный DPI приложениям. Но от этого поломались Qt-приложения, и автор решил не связываться, и откатил фикс. С одной стороны, хорошо — стабильность. С другой грустно. Приходится в настройках XFCE4 выставлять DPI. Это костыль.

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

Мне кажется что в GTK только рендеринг шрифтов реагирует на смену DPI. Виджеты и контролы на твоей гифке остаются фиксированными, только под текст растягиваются.

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

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

О, а можно подробности? ЕМНИП в иксах фиксированный DPI задаётся либо в xorg.conf, либо при запуске через --dpi. И если он не задан ни одним из этих способов — он динамически рассчитывается из геометрии и разрешения. Если монитор отдаёт неправильную геометрию, не соответствующую физическим размерам (это часто так и есть) её можно самому измерить и в xorg.conf прописать в миллиметрах. И по задумке это не только на шрифты должно влиять, но и на всю векторную графику вообще. Но сейчас у всех по умолчанию форсированно 96 стоит, тем или иным способом.

Раньше это всё точно работало, я помню когда то у меня 102 DPI было, исходя из геометрии, и в openoffice a4 на экране соответствовал бумажному a4, как и тестовое приложение «линейка» совпадало с наложенной на экран реальной линейкой. А потом всё это начали ломать...

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

Он жрёт пропорционально настройкам потоков. Поставьте 3 потока - удивитесь, как мало ест.

Спасибо за совет. Нужно будет попробовать.

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

О, а можно подробности?

Вот тут добавили: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/445

Вот тут драма: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1241

Вот тут убрали: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/792

Если монитор отдаёт неправильную геометрию, не соответствующую физическим размерам (это часто так и есть) её можно самому измерить и в xorg.conf прописать в миллиметрах.

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

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

Мне кажется что в GTK только рендеринг шрифтов реагирует на смену DPI. Виджеты и контролы на твоей гифке остаются фиксированными, только под текст растягиваются.

Там немного видно, что кнопки увеличиваются, чтобы текст вместить. И заголовок окна в окнах с CSD тоже увеличивается. Если крутить dpi дальше, то изменение размеров заметно. Так же видно, что кнопки у galculator тоже растягиваются.

Но есть большая беда — иконки не меняют размер, хотя в теме иконок есть варианты с большим разрешением. И перезапуск приложений не помогает. Поэтому кнопки, в которых есть только иконки без текста, вытягиваются по вертикали, но по горизонтали становятся относительно узкими. В Qt-приложении иконки после перезапуска масштабируются.

Странно это. Уже меняются размеры виджетов. Казалось бы, что мешает новые иконки подгрузить. Так что выходит, что да, поломано. Похоже, расчёт на опцию «увеличить всё в два раза», которая в GTK где-то там есть. От неё иконки становятся больше.

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

У лисы очень быстрый поиск по истории, а хромиум может час висеть и одно ядро на сотку жрать. В остальном разница незаметна, попробуй погонять бенчмарки. Например, этот: https://browserbench.org/

InterVi ★★★★
()

Чего-то они перемудрили. У меня hidpi, PixelsPerPx равен 2, все страницы нормального масштаба, а интерфейс стал двойного размера и поле поиска по странице немного опустилось под нижний край.

А, вижу, i-rinat уже об этом написал. Только если я поставлю меньше единицы, придётся масштабировать каждый сайт, который посещаю.

Почитал, что пишут по ссылке, сделал ui.textScaleFactor равный 200, а pixelsperpx поставил в единицу — выглядит нормально и поиск вернулся на место.

Metotron
()
Последнее исправление: Metotron (всего исправлений: 2)

Ну чё сказать… Живи и процветай.

 111      111 
 1111    111
  1111  111
 1111111111
11111111111
11111111111
 1111111111
  111111111
w201403
()
Ответ на: комментарий от InterVi

одна игра летала же, в лисе тормозила.

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

А у меня нормально выглядит. Даже вживую подстраивается: https://imgur.com/a/QAM0SMS.

Так это не иксовый dpi (который сейчас без конфига всегда 96), а Xft.dpi. В Gnome на вяленом есть вместо этого text scaling factor, который равен dpi/96 и который надо брать из gsettings.

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

Так это не иксовый dpi (который сейчас без конфига всегда 96), а Xft.dpi.

Мда. Не знал.

В Gnome на вяленом есть вместо этого text scaling factor, который равен dpi/96 и который надо брать из gsettings.

Это предполагается правилом для всех композиторов? Или только в GNOME?

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

А раньше разве не было VA-API ускорения?

Было, но всегда дефолтом выключено, ибо глюкодром. В ночных сборках дефолтом включено теперь.

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

показ в этом режиме субтитров и титров теперь поддерживается

То есть до этого на каких-то сайтах работало, а на каких-то нет? Оно же должно быть стандартным и не зависеть от сайта.

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

Это предполагается правилом для всех композиторов? Или только в GNOME?

Композитор здесь ни при чем. Это GTK туда смотрит.

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

Но ведь доступ к видеовыходу есть только у композитора. Только он может узнать размеры экрана и соответственно, DPI.

i-rinat ★★★★★
()

Отличный браузер, пользуюсь постоянно

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

Но ведь доступ к видеовыходу есть только у композитора. Только он может узнать размеры экрана и соответственно, DPI.

Все верно, кроме фразы: «и соответственно, DPI». От DPI как такового решили избавиться, оставили text scaling factor, который является чисто пользовательской настройкой и никак (!) не привязан к размерам экрана в миллиметрах и пикселах.

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

и никак (!) не привязан к размерам экрана в миллиметрах и пикселах.

Я всё ещё не могу в такое поверить. Но если это действительно так, это неимоверно глупое решение, поверх которого рано или поздно придётся натягивать костыль.

Реализация соответствующего спецификациям CSS браузера, например, в такой системе будет невозможна. Не получится реализовать размеры в физических единицах. Тот же Libreoffice Writer может попрощаться с возможностью показывать реальный размер шрифтов на реальном размере страницы. Понятие «кегль» для шрифтов просто потеряет смысл. Всё всегда будет разное.

Upd. Открыл страницу в Википедии про кегль. Там в табличке размеров есть столбец «Условный пример», в строках которого размер шрифта содержимого указан через выражения типа <span style="font-size: 6.5pt">Aa</span>. Даже статьи в Википедии поломаются. Фейспалм, тяжёлый вздох, слёзы.

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

Я всё ещё не могу в такое поверить. Но если это действительно так, это неимоверно глупое решение, поверх которого рано или поздно придётся натягивать костыль.

Собсно ты не один такой. И это не первый ребёнок выплеснутый вместе с водою при переходе от иксов к вайланд. Одно из идеологически обоснованных решений, из за которых IMHO вайланд «не взлетит», и его придётся «переизобретать» каким то другим идеологам следующие ннадцать лет.

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

Реализация соответствующего спецификациям CSS браузера, например, в такой системе будет невозможна. Не получится реализовать размеры в физических единицах. Тот же Libreoffice Writer может попрощаться с возможностью показывать реальный размер шрифтов на реальном размере страницы. Понятие «кегль» для шрифтов просто потеряет смысл. Всё всегда будет разное.

Физические единицы применимы только в процессе печати. Один экранный «сантиметр» не равен одному печатному сантиметру. Масштаб подразумевается. И это хорошо - я пишу этот комментарий, используя 32" телевизор в качестве монитора. Если добиваться строгого совпадения, то у телевизора просто не хватит пикселей, чтобы шрифты были красивыми и разборчивыми. Не говоря уже о том, что я сижу дальше от телевизора, чем обычный пользователь от монитора.

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

Масштаб подразумевается.

Никто не мешает организовать масштабирование при доступной информации о DPI. Я вот сейчас открыл в соседней вкладке гугл, крутанул зум, и всё стало в два раза больше. А потом я запустил Writer, и появившаяся страница оказалась в точности по ширине равна реальной странице A4. Я могу её увеличить. Могу уменьшить. А могу установить ползунок в 100% и размер на экране будет такой же, как и размер на бумаге.

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

пишу этот комментарий, используя 32" телевизор в качестве монитора

Он же цветной? Зачем тебе нужен цвет при написании текста? Давайте выбросим цветные мониторы, и вместо них сделаем чёрно-бежевые. Так даже удобнее — глаза меньше будут уставать.

Видишь проблему? На цветном мониторе можно отобразить чёрно-бежевую картинку. На чёрно-бежевом мониторе нельзя отобразить цветную картинку.

Если добиваться строгого совпадения

Не нужно путать возможности с требованиями.

i-rinat ★★★★★
()

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

Qui-Gon ★★★★★
()
Ответ на: комментарий от Jameson

Мне помогает синхронизация профиля с облаком

Спасибо за совет. Так и сделал: создал новый профиль, после - синхронизация.

Что интересно - не все настройки подтягиваются. Так у меня была настроена плавная прокрутка - не подтянулась, надо вручную копировать файл user.js в директорию профайла.

Второе - не подтянулась настройка использования видеокарты для webrender - gfx.webrender.all. Тоже надо настраивать вручную :(

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

На новом профиле - такая же проблема - неожиданно глухо виснет. Девять открытых вкладок, просто переключился по Alt-Tab на FF и всё - висим... Новая версия 103. По сравнению со 102-й - прогресс: в повисшем состоянии быстро закрывается по крестику.

PS: Перешёл бы на Chromium, но не знаю, как там сделать плавную прокрутку, всё перепробовал, по сравнению с FF - всё не то... Проверяю на сайте mail.ru :)

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

Выключи аппаратное ускорение и поработай без него какое-то время

Выключил - прокрутка стала хуже, чем в Chromium. Спасибо, но не вариант.

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

Вообще-то я предлагал выявить виновника зависаний. Чаще всего это именно nvidia и включенное ускорение.

Уже не первая тема с подобными дровами, где решается именно так. Зависания, заикания видео, зависания после сна…

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

Это не решение, конечно, это первый этап, когда уже можно копать дальше - настраивать, писать багрепорты и т.д. и т.п.

Назовем этот метод диагностикой. )

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

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

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

Странно почему у меня не воспроизводится, тоже иксы, тоже нвидия со свежими закрытыми дровами. Сейчас проверил — вебрендер у меня включён по умолчанию, сам я его форсированно через about:config не включал. Впрочем как и «гладкую прокрутку», потому что по моим ощущениям она у меня и так по умолчанию гладкая.

Может ты просто браузер вусмерть ручными настройками умучал? Попробуй с чистым свежим профилем поработать ничего не синхронизируя и ничего в about:config не трогая, без всех своих хаков, как законопослушный чайник. Вдруг он зависать перестанет?

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

Попробуй с чистым свежим профилем поработать ничего не синхронизируя и ничего в about:config не трогая, без всех своих хаков,

У меня там плавная мышка, FoxyProxy без которого я сейчас работать не смогу - ибо блокировками со всех сторон обложили, ну и блокировщик рекламы. Мне работать надо... Может просто багрепорт им написать? Только что им приложить? Ссылку, что я не один такой?

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