Драма, нѣсколькими словами очерченная въ послѣднемъ абзаце предшествующего сообщения, началась ещё в январе 2015 года, когда во блогозаписи «Stickers Done Right» пользователей Телеграма обрадовали извѣстіемъ о появлении поддержки стикеров. Так как тогда в первом из стикерпаков стикеров было не очень много (меньше полутора десятков!), то пользователям предложено было создавать свои собственные стикеры в качестве частично прозрачных изображений и сохранять их в WebP, а каждый клиент Telegram (такой, как Telegram Desktop, напримѣръ) с этого дня начал отображать любой файл WebP, скинутый в чат, в качестве стикера. Во блогозаписи восхвалялася способность WebP хорошо сжимать частично прозрачные изображения — способность, благодаря которой Telegram сдѣлался способным отображать стикеры впятеро быстрее, чѣмъ во прочих мессенджерах. Мѣсяца через четыре (в мае того же 2015 года) не только свои стикеры, но и свои наборы стикеров стало можно создавать, отправляя боту @stickers частично прозрачные изображения в формате PNG, помѣщающиеся в квадрат 512×512 пикселов вплотную (то есть одна из сторон прямоугольника прозрачного холста такого изображения должна быть равною 512px, а вторая — равна или меньше).

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

Если в Telegram Desktop нажать на скрепку и выбрать графический файл для вбрасывания его в чат, то появляется переключатель с позициями «Send as a photo» и «Send as a file». Что помѣшало прибавить к нему ещё третью позицию «Send as a sticker» для всѣхъ графических файлов (или только для WebP), а не создавать тождество сущностей «WebP» и «стикер»?

Если разработчики Telegram обнаружили (и похвалили!) высокую эффективность сжатия WebP, то что могло заставить их ограничиться её использованием только для стикеров? Почему нельзя хранить в этом формате и многое другое для экономии объёма и для ускорения передачи и приёма? Разве нѣтъ таких изображений, которые можно было бы конвертировать при отправке не в JPEG с потерями, а в lossless WebP без потерь, причём попробовать при отправке оба формата и выбросить JPEG, если файл lossless WebP меньше его, и тѣмъ достигнуть экономии по объёму, а не одной только безупречности внѣшняго вида нѣкоторыхъ изображений? (Подозреваю, что изрядная часть канала @PixeLove могла бы и обойтись без проJPEGовывания, и приходить к подписчикам побыстрее.) А разве нѣтъ таких GIF-анимаций, которые можно было бы конвертировать при отправке не в MP4 с потерями (и начать это с 2016 г.), а в анимированный lossless WebP без потерь (и начать это с 2015 г.), и притом с большей экономией по объёму? (Вряд ли вышеупомянутый примѣръ из хвоста гугловского FAQ о WebP единственен.)

А что там с использованием WebP не как внутрителеграмного хранилища, а как первоисточника изображения (пускай затѣмъ и преобразуемого в JPEG или MP4 при отправке)? Как можно восхвалять формат WebP за его степень сжатия изображений, но не готовиться к тому, что люди в так называемом реальномъ мірѣ (за предѣлами Телеграма) также пользуются этим форматом (восхваляя его также и за то же) и оттого они начнут рано или поздно притаскивать и в Telegram используемые ими изображения в файлах WebP — да такие, при создании которых никто и не мыслил об этих изображениях как о стикерах для Телеграма? Почему на эти файлы нельзя воздѣйствовать переключателем с позициями «Send as a photo» и «Send as a file»? Если во блогозаписи «Stickers Done Right» от стикера требуется прозрачность, то почему непрозрачные изображения из файлов WebP также стикеризуются? Если бот @stickers требует от стикера соѿвѣтствіе опредѣлённымъ размѣрам, то почему изображения из файлов WebP других размѣровъ также стикеризуются? Наконец, если анимированными стикерами работают не анимированные WebP, а экспортированные векторные изображения из Adobe After Effects, то почему из содержимого файлов animated WebP вырѣзается первый кадр анимации и также стикеризуется?

После ряда экспериментов можно догадываться, что и разработчики в Telegram также набрели на нѣкоторые из только что заданных мною вопросов (разумѣется, набрели даже раньше, чѣмъ я успѣлъ задать их) — и, задавшись ими, пришли к выводу о том, что придавать вид стикеров достаточно крупным файлам WebP не слѣдуетъ: методом тыка можно обнаружить, что достаточно крупные файлы WebP всё-таки отображаются почти «как файл» и в Telegram под Android, и в Telegram Desktop под Windows.

Я пишу «почти», потому что всякий другой файл, отправляемый «как файл», можно снабдить текстовою подписью до его отправки (а если выбрать в контекстном меню пункт редактирования, то и после отправки), однако же этакие достаточно крупные файлы WebP снабдить текстовою подписью никоим образом нельзя.

А ещё я неопредѣлённо пишу «достаточно крупные», поскольку это понятие, по-видимому, не было чётко опредѣлено и одинаково реализовано разработчиками. Можно обнаружить (и я обнаружил) такой файл WebP, который в Telegram Desktop под Windows будет выглядеть почти «как файл», однако в Telegram под Android будет показан как стикер. Болѣе того: это понятие, по-видимому, не привязано къ размѣру файла, так как можно обнаружить (и я обнаружил) два таких файла WebP одинаковаго размѣра (1920×2668 пикселов), из которых один файл (большего объёма, потому что lossless WebP) будет показан в Telegram под Android почти «как файл», а другой файл (меньшего объёма, потому что lossy WebP) в Telegram под Android будет показан как стикер.

То и другое и третье я считаю багом, о чём и сообщил в @BugReports, приложив всѣ обнаруженные примѣры.

Но иррациональность ситуации вокруг WebP в Telegram не исчерпывается вышеизложенными вопросами: можно задавать и другие.

Какое поведение разработчики Telegram вообще считают нормальным для такого пользователя, которому надо отправить WebP не как стикер, а как иллюстрацию или как файл? Зачѣмъ принуждать пользователя к преобразованию изображения из одного формата в другой при посредстве сторонней программы или чужого сайта, если сам Telegram, когда рѣчь идёт не о WebP, невозбранно способен прочитать изображение из PNG и пересохранить в JPEG? Мы же знаем, что и из WebP он также умѣетъ читать.

А какое поведение разработчики Telegram вообще считают нормальным для такого пользователя, которому пришёл одиночный стикер (в формате WebP) и которому стикер настолько понравился, что пользователь захотел прибавить его къ нѣкоторому стикерпаку, но бот @stickers принимает только PNG и с болѣе жёсткими требованиями къ размѣру? Почему бот @stickers не принимает готовые WebP даже в том случае, когда они подходят по размѣру? (Если разработчики бота @stickers создают стикерпаки только в формате lossy WebP и притом опасаются накопления ошибок сжатия от послѣдовательных пересохранений из lossy WebP в lossy WebP, то можно же хотя бы lossless WebP принимать? Если были дополнительные опасения насчёт того, что начнут тогда из lossy WebP в lossless WebP перегонять для обхода ограничения, то тогда что мѣшаетъ сейчас из lossy WebP в PNG перегонять для обхода ограничения?)

Почему стикеры могут содержать прозрачные области, а обыкновенные иллюстрации — не могут? Нельзя ли частично прозрачные изображения обнаруживать и перегонять не в формат JPEG (вообще не поддерживающий прозрачность), а в формат WebP (дѣлая автоматический выбор в пользу lossy WebP или lossless WebP по объёму файла)?

Если анимированные GIF объёмом до 10 мегабайтов преобразуются в MP4 (для экономии объёма и траффика), а больше 10 мегабайтов не преобразуются (чтобы преобразовальник не надорвался), но всё же показываются анимированными, то нельзя ли то же самое дѣлать и с анимированными WebP, и с анимированными PNG? Какое поведение разработчики Telegram вообще считают нормальным для такого пользователя, которому нужно отослать анимированный WebP или анимированный PNG? Можно ли надеяться, что пользователь возьмёт в руки FFmpeg и самостоятельно создаст MP4 с потерей качества, если этакий-то пользователь может взять в руки и gifski, тѣмъ болѣе что объём получающегося GIF в Telegram ограничен аж 1½ гигабайтами?

Закончив задавать перечисленные выше вопросы, остаётся только накрыть лицо рукою, не в силах с ужасом вглядываться в грядущее. Если про Twitter и про imgur и про Telegram можно сказать, что они воздерживаются от настоящей поддержки формата WebP (который появился в 2010 году) и поддержки анимированных PNG (браузерная поддержка которых началась в 2007 году), то тогда откуда же взять нам столько терпения, чтоб хватило аж до того ≈2030 года (если не далѣе), в котором эти сайты такими темпами наконец сподобятся по-настоящему поддержать всѣ тѣ новѣйшіе форматы, которые явились или ещё явятся в сáмое ближайшее время, изобилуя достоинствами?

Выше я упоминал, напримѣръ, что поддержка графического формата AVIF приуготавливается в движке Chromium — но и Фонд Мозиллы не отстаёт, так что и поддержка в Файерфоксе также приуготавливается. Получается, что без AVIF останется та же доля пользователей, что и без WebP: и поклонники старого Internet Explorer (а не нового Microsoft Edge), и пользователи iOS, и ненавистники Firefox Quantum — так не станут ли зажимать его точно так же, как WebP сейчас? Будут ли в Twitter и в Telegram перегоняться иллюстрации из AVIF в JPEG, будет ли анимированный AVIF преобразовываться в MP4 или обрѣзаться до первого кадра с последующим JPEGованием, будет ли imgur проглатывать AVIF и выплёвывать ошибку? Или всё же примѣръ компании Netflix, пришедшей к употреблению AVIF вмѣсто JPEG, кого-нибудь чему-нибудь научит?

А как выглядит будущность того видеоформата AV1 (на формате ключевых кадров из которого основывается AVIF) — видеоформата, который прямо сейчас поддерживается тѣмъ же крýгом браузеров (Chromium да Firefox) всюду, кроме мобильных устройств, ещё не доросших до необходимой вычислительной мощности или специальной аппаратной поддержки? Будет ли AV1 радовать наше зрѣніе итогами примѣненія фильтра CDEF, предотвращающаго эффект «замыливания» чётких контуров в кадре, или AV1 ожидают долгие годы преобразования в AVC на стороне сервера или вообще отбрасывания за непонятность?

Значительно ли количество тѣхъ разработчиков движков фотохостинговых, или имиджбордовых, или микроблогосферических, или мессенджеровых, которые прямо сейчас с надеждою вглядываются в открытый исходный код будущей эталонной реализации формата JPEG XL и ждут от неё хотя бы той экономии пространства и траффика, которую обѣщаетъ обратимое преобразование из JPEG в JPEG XL без потерь? А когда менеджмент компании Netflix принимал решение о переходе на AVIF, там хоть кто-нибудь оговорился «ну это только на ближайший год, а там уж и JPEG XL подоспѣетъ»?

А не видно ли на горизонте цѣлое восходящее созвѣздіе новых видеоформатов? Во-первых, от Joint Video Experts Team к концу нынешнего (2020) года ждут видеостандарт VVC (он же, насколько я понимаю, MPEG-I Part 3), предназначенный стать слѣдующим шагом на том пути развития, на котором AVC и затѣмъ HEVC были предшествующими шагами. Во-вторых, шаг HEVC решили, так сказать, правильно переповторить: в феврале на сайте Bitmovin и в марте у Diego Gibellino можно было прочесть, что опять же к концу нынешнего (2020) года ожидается появление стандарта EVC (он же, насколько я понимаю, MPEG-5 Part 1), в котором базовый профиль будет свободным от лицензионных отчислений (а всё же сжимать кадры до 30% лучше, чѣмъ въ AVC при равном качестве), а поверх него будут работать коммерческие дополнения (способные на ¼ превзойти даже HEVC 10 Main), задуманныя какъ отключаемыя, но для заманухи называемыя «основным профилем» (main profile). В-третьих, постепенно обретает форму (уж не знаю, насколько это сейчас официально) задумка LCEVC (MPEG-5 Part 2) с двумя слоями корректирующих поправок, позволяющими хранить основную видеозапись в половинном разрешении (скажем, HD вмѣсто QHD — или, скажем, FullHD вмѣсто 4K) для экономии объёма файла (а значит, и траффика) и вычислительной мощности, но всё же обретать чёткость кадра после наложения корректирующих поправок.

Если ещё даже поддержку WebM в Twitter и в Telegram не завезли, то долго ли дожидаться, къ примѣру, EVC baseline? — посѣдѣть можно будет гораздо раньше, чѣмъ дождаться.

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

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

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

Прочитав на канале «Джига на могиле» (@jiganamogile) вчерашние слова осуждения насчёт новой функции в Telegram, обеспечивающей возможность редактирования сколь угодно старых сообщений на каналах, я счёл нужным удѣлить десяток минут собственному рассуждению о том, какую пользу принесёт нам эта новинка, как с её появлением каналы в Telegram способны принять нѣсколько менѣе блогосферический и болѣе вики-подобный облик (с дописками, с поправками, с постскриптумами, с перекрёстными ссылками, с продолжительным пополнением оглавлений), какую дополнительную пользу поэтому могли бы принести разработчики Telegram, кабы предусмотрели историю правок (как в вики или как на Гитхабе) и притом ещё обеспечили дополнительное пространство для дописок, нарастив предѣльный объём сообщений во много раз (или хотя бы вдвое, как в Твиттере, позволив использовать вдвое больше таких символов, код которых в таблице Unicode не превосходит U+07FF и оттого в кодировке UTF-8 укладывается в двухбайтовом пространстве вмѣсто четырёхбайтового).

Приведённое выше десятиминутное рассуждение я сперва выложил в чате @tginfochat, но теперь оно будет и у меня на канале, и на канале @jiganamogile также доставлено.

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

Он содержит, в частности, ретвиты сравнений пельменей с костюмами Met Gala.

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

28 апреля появилась новая, долго готовившаяся, версия реализации P2P-распределённой файловой системы IPFS на языке Go — версия 0.5.0, содержащая множество улучшений (в частности, ускоренную работу DHT), множество полезных новинок (в частности, раздачу ѿдѣльныхъ доменных имён ѿдѣльнымъ CID при гейтовании).

Без значительного промедления (ужé на слѣдующій день — 29 апреля) я установил себѣ эту версию — и только тогда обнаружил: единственным, что работало, был демон файловой системы. Расширение IPFS Companion, установленное во браузере, не могло соединиться с демоном даже для того, чтобы показать количество соединений P2P. Также и web-интерфейс демона сообщал о невозможности соединиться с ним.

Обвинять в этой неработоспособности саму реализацию файловой системы я, однако же, никак не мог. Возникшая передо мною драма превозмогания имѣла другую причину: измѣненія, внесённыя в код web-интерфейса и расширения для соѿвѣтствія новинкам реализации IPFS, совершались на достаточно новой версии языка JavaScript, и оттого ужé не поддерживались используемым мною web-браузером.

Постоянные читатели моего блога ужé видѣли, что за нѣсколько послѣднихъ лѣтъ я нѣсколько раз упоминал о печальной судьбе тѣхъ пользователей браузера Mozilla Firefox, которые первоначально были привлечены к его использованию тѣмъ, что именно в Файерфоксе (впервые в истории браузеростроения) появилось множество API (программных интерфейсов), позволявших сторонним программистам создавать дополнения и расширения функциональных возможностей браузера. Много лѣтъ пользователи могли почти неограниченно наслаждаться или даже повседневной жизни своей не мыслить без тѣхъ возможностей, которыми обогащали Firefox эти дополнения: совершалось блокирование надоедливых рекламных блоков и призывов к регистрации, работали встроенные во браузер IRC-чатники и СУБД, перестанавливались и перестраивались и перекрашивались панели управления (и обвѣшивались дополнительными кнопками и индикаторами), реорганизовывались скачиваемые файлы, выяснялись цвѣта и метаданные изображений, появлялись удобные возможности поиска по словарям и по изображениям, дополнялось оформление и поведение нѣкоторыхъ сайтов. Но изрядная часть этих возможностей погибла, когда в августе 2017 года был объявлен, а затѣмъ в ноябре 2017 года (с выходом версии Firefox 57 под кодовым именем «Quantum») был реализован полный отказ от прежних API в пользу нового стандарта WebExtensions — стандарта болѣе безопасного, болѣе подходящего под новый многопоточный движок браузера, а также (это важно!) куда болѣе похожего на используемый в популярном браузере Google Chrome (а значит, изрядно уменьшившего усилия авторов, сочиняющих свои расширения для Chrome и для Firefox одновременно), однако обладающего меньшими возможностями API, так что ожидаемое поведение и даже само существование многих предшествующих расширений сдѣлалось технически невозможным.

Ужé к августу 2018 года накопилось достаточно статистики для того, чтобы я утверждал в Фидонете, что Firefox этим шагом самоубился (доля его пользователей прекратила расти, хотя предшествующие четыре месяца она росла). А в нынешнем апреле я измѣрялъ количество пользователей Файерфокса, до сих пор не получивших поддержку формата WebP (слѣдовательно, использующих Firefox 64 или болѣе ранний), и выложил в Твиттере результат: таких пользователей — примѣрно одна седьмая (а в России ещё больше — примѣрно одна пятая). То есть и отток пользователей (в том числе — потенциальных) произошёл, и проявилась склонность пользователей оставаться на старых доQuantumных версиях Файерфокса.

Не думайте, что всё это время я упоминал всё это из бескорыстной сострадательности къ сотням тысяч пользователей прежних расширений, которые были ущемлены из-за выхода Firefox Quantum! — нѣтъ, я и сам принадлежал к их числу, с 2017 года оставался вѣренъ болѣе ранней версии Файерфокса и терпел невозможность открывать ею графические файлы в формате WebP (поддержка которого появилась в Firefox 65) или видео AV1 (их поддержку ≈нормально добавили только в Firefox 67).

А вот ради IPFS я не утерпел — перешёл на Firefox 75.

Упомянутый в предшествующем сообщении переход к использованию браузера Firefox 75 оказался для меня менѣе неприятным, чѣмъ если бы я сразу перешёл в ноябре 2017 года на Firefox 57. Тогда, ≈2½ года тому назад, я был бы вынужден опираться на повседневное использование только таких расширений Файерфокса, которые смогли сохраниться с переходом на новые API: Adblock Plus, ColorZilla, HTTPS Everywhere, Image Search Options, IPFS Companion, Nuke Anything, Show fixed Go, Violentmonkey, Web Developer — но одних их мнѣ, конечно, недоставало бы. Однако к 2020 году с течением времени появились замѣнители многих оставленных в 2017 году расширений.

Напримѣръ, явилось расширение Copy Link Text на основе API WebExtensions, способное замѣнить аналогичное прежнее расширение — единственное различие состоит в том, что добавляемые новыми расширениями пункты контекстного меню всегда располагаются ближе к хвосту, а прямо под встроенным пунктом «Copy Link Location» такому новому пункту не быть. Явился и нѣсколько болѣе навороченный аналог — Link Text and Location Copier.

Ещё примѣръ: явилось расширение Foxy Gestures на замѣну прежнему расширению FireGestures для поддержки управления жестами, мышóю совершаемыми. Новые API налагают бóльшие ограничения: жесты не работают ни на мозаике страниц, наполняющей свежеоткрытую вкладку, ни в просмотрщике исходного кода, ни в настройках расширений, ни в перечне расширений на сайте Фонда Мозиллы — но за этим видна логика достижения большей безопасности, и притом в «обычном» web-сёрфинге на эти ограничения нельзя наткнуться, так что они не мѣшаютъ.

Гораздо болѣе тяжёлою является драма превозмогания, окружающая расширение Tab Mix Plus, поскольку большинство необходимых ему интерфейсов просто-напросто отсутствуют в новых Файерфоксах. Автор этого расширения создал показательное расширение «Tab Mix — Links», еле-еле служащее аналогом одной только (первой) страницы настроек прежнего расширения Tab Mix Plus — и эта страница состоит теперь в основном из подсказок о том, какую настройку пользователю слѣдуетъ самостоятельно совершить в Файерфоксе для достижения того или иного желаемого поведения гиперссылок, потому что сам API расширений перемѣнить эту настройку не способен.

В качестве аналога ещё одной возможности Tab Mix Plus — возможности сохранения и восстановления сеанса (то есть всего окна со всѣми открытыми в нём вкладками web-страниц) — сейчас наиболее популярно расширение Tab Session Manager другого автора, но и оно едва насчитывает 130 тысяч пользователей (блѣдная тѣнь прежней многосоттысячной аудитории менеджеров сеансов!) и притом сильно страдает от ограничений API, будучи в состоянии восстановить только послѣднюю из страниц, открывавшихся во вкладке (а не всю историю посещений), и притом не будучи способным нормально задать даже значок на вкладке, загрузка страницы в которую откладывается (чтобы не перенагрузить браузер при восстановлении сеанса, насчитывающего сотни страниц), так что задание значка приходится обеспечивать загрузкою в той вкладке специальной заглушки со странным адресом.

Нечѣмъ контролировать и порядок открываемых вкладок: вмѣсто этого приходится самому перемѣнять настройки «browser.tabs.insertAfterCurrent» и (или) «browser.tabs.insertRelatedAfterCurrent» на странице «about:config», да и то без окончательной гарантии результата.

Нѣтъ настроек, контролирующих то, какая вкладка дѣлается активною после закрытия нынешней — если не считать настроек закрытия вкладки жестом из Foxy Gestures.

Чтобы получить список недавно закрытых вкладок, служащий для отмѣны состояшегося закрытия вкладок, мнѣ пришлось поставить ѿдѣльное расширение — Undo Close Tab.

Располагать вкладки во много рядов также не получится. (Есть сборник стилевых модификаций, придающих новым Файерфоксам старый вид, и вкладки во много рядов там также есть — но, оказывается, ѿ этого сходит с ума подсистема перетаскивания вкладок, совершаемого для измѣненія их порядка, потому что её проектировали с расчётом на единственный ряд вкладок.)

Нѣтъ и возможности убирать и добавлять пункты контекстного меню, присущего корешкам вкладок.

Но всё-таки часть функций расширения Tab Mix Plus, перечисленных в моём предшествующем сообщении, взяли на себя другие расширения или внутрифайерфоксовые настройки. Того же нельзя сказать о цѣломъ рядѣ других расширений, которые погибли цѣликомъ и невозвратно.

Напримѣръ, нѣтъ и быть не может аналогов для расширения «Add Bookmark Here²», добавлявшего в каждую папку закладок удобную кнопку, служащую для прибавления открытой страницы именно к этой папке.

Напримѣръ, нѣтъ и быть не может аналогов для расширения «Clean and Close», добавлявшего в список закачек удобную кнопку, позволявшую одновременно очистить этот список и закрыть окно его.

Напримѣръ, нѣтъ и быть не может аналогов для расширения «ErrorZilla Plus», добавлявшего на страницу ошибки удобные кнопки, позволявшие достать желаемую страницу (оказавшуюся недоступною ввиду ошибки) из альтернативных источников: из Архива Интернета, из кэша Google, и так далѣе — или попинговать недоступный сайт.

Вроде бы нѣтъ и аналогов для расширения «Live HTTP Headers», позволявшего въ ѿдѣльномъ окнѣ в развёрнутом виде разглядывать заголовки всѣхъ HTTP-запросов и HTTP-откликов (а не тратить время на разворачивание их по одному, как это устроено в нынешнем ѿладчикѣ). Возможно, Netmon сдѣлается таким аналогом в будущем — но пока его список заголовков грѣшитъ неполнотою свѣдѣній.

Также нѣтъ и быть не может аналогов для расширения «Searchbar Autosizer», перемѣнявшего размѣръ поля поиска по мѣрѣ набора текста в нём: нынешние API, по-видимому, не способны вмѣшиваться в стили интерфейса браузера.

По-видимому, не появилось нормальных аналогов для расширения «SQLite Manager», позволявшего открывать и измѣнять базы данных в сáмом популярном их формате — SQLite. Появившиеся аналоги лишены прежней приятности цвѣтного табличного интерфейса.

По-видимому, нѣтъ и не будет прямых аналогов для расширения «Classic Theme Restorer», способного обеспечивать бóльшую компактность интерфейса — разве что ужé упоминавшийся сборник стилевых модификаций (я его ещё не смотрѣлъ) может содержать нѣчто подобное — так что пока что я вынужден увеличить размѣръ корешка вкладки (задаваемый настройкою «browser.tabs.tabMinWidth»), у меня бывший равным 48 пикселам (это одна сороковáя часть ширины экрана FullHD), до 60 пикселов (тридцать вторая часть той же ширины экрана). По умолчанию же в новых Файерфоксах он равен 76 пикселам, но пока ещё я никак не могу стерпеть то, как медленно (болѣе чѣмъ на ¼ медленнѣе) при такой настройке проматываются вкладки при нажатии на стреловидные кнопки по бокам однорядной панели вкладок, так что я поневоле остановился на шестидесяти пикселах.

Насколько я могу судить, также не появилось ни одного аналога расширения «UnMHT», способного открывать файлы MHTML — да и не появится, если правда то, что сказано в описании к расширению Save Page WE: в API WebExtensions не предусматривается чтение локальных файлов.

Я с удивлением обнаружил, что также не существует и аналога для расширения «Work Offline», обеспечивавшего видимость того переключателя между онлайновою и оффлайновою работою, который существовал ещё со времён Netscape Navigator, а теперь закопан глубоко в меню без надежды на ясную видимость.

Так как расширение FlashGot тоже не поддерживается в новых Файерфоксах, то я решил вмѣсто него остановиться на употреблении расширения Download Master совмѣстно с одноимённым менеджером закачек. В поведении этого расширения опять же замѣтнымъ оказалось недостаточное удобство API WebExtensions: так как API не позволяет дополнять новыми пунктами выпадающие списки в диалоговых окнах самогó браузера, то никак не возможно вручную всякий раз выбирать для каждой закачки, будет ли скачивать её Firefox или DM, и потому́ этот выбор дѣлается автоматически — в зависимости от объёма файла.

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

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

В новых Файерфоксах, по-видимому, погибли и прежние темы оформления, тему придётся подбирать заново (стоявшая у меня — начисто пропала при обновлении браузера), пока что я остановился на использовании «Brushed Metal — OSX». Вообще же очень многие темы оформления, на сайте Фонда Мозиллы находящиеся в списке самых популярных, вызывают у меня самое настоящее изумление своею популярностью, поскольку выглядят слишком художественно выразительными для того, чтобы всерьёз пользоваться ими: ну как это на их фоне вообще можно что-то прочесть (скажем, на корешке у вкладки, чтобы отличить её от соседствующих), не напрягая человѣческое зрѣніе до послѣдней крайности?

Кроме того, в новых Файерфоксах над страницею всегда располагается панель управления (с кнопками и строкою адреса), а вкладки — всегда над этой панелью, а не под нею. Соѿвѣтственно, у полноэкранного окна браузера в том левом верхнем углу, в который надёжно упирается курсор мыши, расположена не кнопка «Назад», а кнопка движения по ряду вкладок налево. Сперва я подумал было, что этакое расположение выглядит скудоумным, то есть что проектанты его не имѣли ни малѣйшаго представления о том, как воспользоваться законом Фиттса на пользу надёжного попадания по кнопке «Назад». Но после нѣсколькихъ дней употребления Файерфокса именно в таком виде, какой он приобрёл въ послѣдніе 2½ года, то есть с его невозможностью располагать корешки вкладок въ нѣсколько рядов, и притом ещё с узостью единственного ряда (во-первых, в нём нельзя подавить появление кнопок, перелистывающих налево или направо, или появление кнопки, вызывающей выпадающий список вкладок, а вѣдь всѣ три эти кнопки занимают мѣсто; во-вторых, так как этот ряд располагается над панелью управления, то именно в нём закладывается ещё и мѣсто под управляющие окном угловые кнопки; всё это приводит к тому, что в этом ряду еле-еле выстраивается всего-навсего двадцать восемь таких корешков вкладок, которые у меня имѣютъ шестидесятипиксельную ширину, то есть каждый из них занимает всего-навсего тридцать вторую часть ширины экрана FullHD) — после этого я убедился на своём опыте, что именно такой Firefox требует от пользователя, открывшего хотя бы три десятка вкладок (не говоря уж о нѣсколькихъ сотнях их), полной готовности очень часто перелистывать их туда-сюда — и при таком образе жизни кнопка, служащая для движения по ряду вкладок налево, оказывается замѣтно чаще нужною, чѣмъ даже кнопка «Назад», так что очень правильно в её пользу заставили работать закон Фиттса.

Хорошо ещё, что в расширении Foxy Gestures я заблаговременно настроил жест мышóю, позволяющий подать команду «Назад» из любого мѣста на странице, а также и два жеста для простейшей навигации по вкладкам («открыть предшествующую вкладку» и «открыть послѣдующую вкладку») — однако же для болѣе сложных переходов мнѣ всё-таки придётся пролистывать ряд вкладок или выпадающий список их.

Ключевое, важнейшее ѿличіе ѿ ситуаціи с многорядными вкладками состоит в том, что при однорядных вкладках остро ощущается (и не просто ощущается, а является реальным фактом повседневной жизни) именно то обстоятельство, что если открыть три десятка вкладок, то не всѣ онѣ будут одновременно видными в одном ряду, а если открыть болѣе полусотни, то и в выпадающем списке всѣхъ вкладок онѣ не всѣ будут одновременно видными. В 2017 году можно было обозреть хоть тысячу вкладок (достаточно двадцати пяти рядов вкладок, показывающих по сóрок корешков вкладок в каждом ряду), прибегая к помощи Tab Mix Plus, но в новых Файерфоксах сама возможность достигнуть такой обозримости была утрачена корешками вкладок.

Можно подозревать (и подозреваю), что утрата обозримости многих десятков вкладок, упомянутая въ послѣднемъ абзацѣ предшествующаго сообщенія, устроена была разработчиками намѣренно, то есть как нѣкое удобное средство, позволяющее дѣятельно стремиться к тому, чтобы пользователи новых Файерфоксов придерживалися своего рода информационной диеты, открывая как можно меньше вкладок, сознательно или подсознательно желая их обозримости — и тѣмъ самымъ способствовали и уменьшению усилий браузера, пропорциональных числу вкладок, и уменьшению потребления оперативной памяти. (Извѣстно, что Фонд Мозиллы стремился уменьшить потребление оперативной памяти хотя бы для того, чтобы невозбранно перейти в марте 2019 года к употреблению восьми параллельных процессов вмѣсто четырёх.) Для пользователей вроде меня (обновлением Файерфокса принуждённых помимо воли отказаться от прежних возможностей Tab Mix Plus) этакая информационная диета выглядит довольно суровою необходимостью сократить количество вкладок на порядок и даже болѣе — так, напримѣръ, лично у меня к концу апреля оставалось болѣе шести сотен открытых вкладок, о каждой из которых я думал (и небезосновательно): «Ѽ, вот интересный материал: надо бы не только прочесть его, но и позже упомянуть во блоге — а пока что пусть во вкладке повисит». И я очень рад был, что отыскалось расширение tabs2txt, позволившее утащить из прежнего Файерфокса полный список открытых вкладок в обыкновеннѣйшемъ текстовом виде (по одному адресу открытой страницы на каждой строке текста), так что список не был утрачен, а был вставлен мною в новом Файерфоксе в расширение Tab Session Manager, импортирован как готовый сеанс. Но теперь я буду, буду постепенно сокращать количество открытых вкладок: никуда не деться от этого. Получается, что в 2020 году всѣмъ моим читателям предстоит видеть у меня во блоге множество новых записей (и прежде всего — кратких микроблогозаписей в Твиттере, не требующих значительных усилий), и в записях этих я буду упоминать такие довольно давно прочитанные свѣдѣнія и обстоятельства, до которых примѣрно за 2½ года (а до нѣкоторыхъ — за болѣе короткое или болѣе продолжительное время) ещё не дошли руки у меня, а вот теперь (под давлением современных нюансов браузеростроения) всё же дойдут онѣ, да ещё как дойдут-то!

Что же касается невозможности добавить вертикальный раздѣлитель или нерастяжимый пробѣлъ из интерфейса настройки панелей инструментов в Файерфоксе (невозможности, о которой я упоминал ещё одним сообщением раньше въ послѣднемъ абзацѣ), то существует обходной путь достижения желаемого, упоминаемый на форуме MozillaZine и также ещё на сайте Super User. Суть его состоит в том, чтобы на странице «about:config» вмѣшаться в значение настройки «browser.uiCustomization.state», значение которой записывается, по-видимому, на языке JSON и содержит массив под названием «nav-bar», перечисляющий идентификаторы всѣхъ элементов навигационной панели инструментов. Если через запятую дописать в этом массиве ещё один идентификатор, начинающийся словами «customizableui-special-separator» и заканчивающийся уникальным номером, то на панели появится вертикальный раздѣлитель, а если через запятую дописать в этом массиве ещё один идентификатор, начинающийся словами «customizableui-special-spacer» и заканчивающийся уникальным номером, то на панели появится нерастяжимый пробѣлъ. Появится, впрочем, только после перезагрузки браузера.

А ещё один досадный недостаток интерфейса новых Файерфоксов состоит в том, что ещё 11 декабря позапрошлого (2018) года с выходом Firefox 64 Фонд Мозиллы решил отказаться от встроенного читальника RSS-потоков, так что читать RSS (или Atom, или другие подобные форматы) теперь можно только после установки одного из популярных расширений, возвращающих в Firefox эту способность. Для начала я установил RSSPreview для обнаружения RSS-потоков на сайтах и для предпросмотра RSS-потоков по одному; но я знаю, что существуют и навороченные каталоги-читальники RSS-потоков съ раздѣленіемъ источников на подкатегории и с генераторами лент чтения — среди таковых Feedbro выглядит наиболѣе популярным.

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

Он содержит, в частности, ретвиты статистических данных об употреблении эмоджи в Твиттере.

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

Он содержит, в частности, ретвиты новинок Гитхаба.

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

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

Он содержит, в частности, ретвиты сообщений 12 мая о смерти Крылова и затѣмъ о фиаско криптовалютного проекта TON в тот же день.

Я очень глубоко скорблю.

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

Он содержит, в частности, ретвиты сообщений о том, что работа кодировщика rav1e была замѣтно (на десятки процентов въ нѣкоторыхъ режимах работы) ускорена его разработчиками.

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

Он содержит, в частности, ретвиты микроблогозаписей о выдающихся качествах древесины того дерева, которое называется «павловния войлочная».