#баг дня

Встречали ли вы баги, которым восемь лет?

А вот есть такие! Причём, казалось бы, подобное уже давно должно было быть решено... но нет.

Итак, встречайте: https://bugs.chromium.org/p/chromium/issues/detail?id=507397

Суть бага в следующем: для inline-flex контейнера (а ранее и для flex) неверно рассчитывается ширина (а у кого-то и высота) в случае column wrap раскладки (flex-flow). Демо: https://codepen.io/anon/pen/pJLwYp

Смешное хотите? Microsoft Edge, который ещё на старом движке почти от IE, с этим справлялся без проблем. А вот все современные браузеры так или иначе валились.

Исправлено в грядущем Chrome 116.

#bug #chrome #edge #flex

#баг дня

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

Так что же не так с этим поведением?

Ну, для начала, оно очень непросто отключается. А точнее, не отключается — можно только переопределить. А во-вторых, стоит вам поставить фоновую картинку на ваше поле, для, например, иконки — как Хром и её сотрёт. Вот, посмотрите сами: https://codepen.io/alinaki/pen/oNQyGjo?editors=1100

Повторю: поведение касается только автоматически заполненного текста.

Сразу скажу, что официально это багом не признано и разработчики Google Chrome вертеть нас всех хотели на своих won't fix-ах: https://bugs.chromium.org/p/chromium/issues/detail?id=46543

Какие у нас есть варианты? Вообще, несколько. Все — буквально хаки.

1. Установить атрибут autocomplete в "new-password" или в любое случайное значение. Отключит автозаполнение вообще.
2. Повесить слушатель на событие change поля и восстанавливать стили скриптом.
3. Убрать заполнение цветом можно через игры с transition, например:

input:-webkit-autofill {
  transition: all 9999s;
  transition-delay: 9999s;
}

...в кодпене выше так и сделано. Но картинке это никак не поможет, потому что background-image не анимируется.

На протяжении всех этих более 10 лет разработчики Chrome и WebKit вообще активно меняли способы заливки полей, поэтому вариантов обхода можно найти десятки. Вот только абсолютное большинство из них стало или бесполезно, или попросту неудобно.

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

#chrome #autocomplete #bug

#баг дня

Сегодня Google опрокинул миллионы пользователей расширений Google Sheets.

Для многих станет сюрпризом, но этот рынок огромен: аналитика, SEO, рассылки, бюджет, ведение рекламных кампаний, анализ опросов из Google Forms... всё там.

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

Так вот, когда-то давно в Chrome 83 появилась очередная директива Content-Security Policy (CSP): Trusted Types.

MDN: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/trusted-types

Web.Dev: https://web.dev/articles/trusted-types

Когда она включена, любую загрузку скриптов надо предварительно одобрить. Любое изменение innerHTML и документа вообще — тоже.

Звучит разумно? Давайте дальше.

Практически любой скрипт на свете использует innerHTML, но это полбеды. Если директива неправильно описана, загрузка и исполнение скриптов внутри iframe тоже становится невозможной.

И сегодня в Google Sheets появился заголовок, включающий директиву, а код настройки — нет.

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

Ах да, директива учитывается только в Chrome 🤡

Баг-трекер: https://issuetracker.google.com/issues/313466551

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

А решение, собственно, заключается в минимальной настройке директивы.

Это то, что должны были сделать разработчики Google Sheets:

<script>
  if (window.trustedTypes && window.trustedTypes.createPolicy) {
    window.trustedTypes.createPolicy('default', {
      createHTML: string => string,
      createScriptURL: string => string,
      createScript: string => string,
    });
  }
</script>

В общем, день был насыщенный.

P. S. По состоянию на 23:00 EET, Google откатывают изменения.

#google #sheets #workspace #bug

#баг дня

Кастомные скроллбары — штука прекрасная, хоть за 20 лет так и не нашедшая свой путь в стандарты. До сих пор полноценная стилизация возможна только в Blink aka Chromium и WebKit aka Safari.

В Firefox как не работало, так и не работает.

К слову, хорошая статья Ахмада Шадида на тему: https://ishadeed.com/article/custom-scrollbars-css/

Короче, суть бага: если вы решились таки стилизовать скроллбар, то не рассчитывайте, что Safari правильно применит стили по наведению мыши :)

Я, правда, не знаю, кому может прийти в голову менять стили скроллбара по hover.

Раз сработает, два сработает, а на третий — всё, нет. Смотрим видео, собственно.

Решение от Брамуса Ван-Дамма довольно забавное: нужно стриггерить инвалидацию стилей, для чего можно рандомной CSS-переменной присвоить неопределённое значение. Вот так:

.section:hover {
  --force-rerender: ;
}

Странные вайбы такие... IE-шные.

Короче, как будет ссылка на официальный багтрекер — закину.

Upd. Ссылка на багтрекер: https://bugs.webkit.org/show_bug.cgi?id=267575

#css #scrollbar #safari #bug

#баг дня

Кастомные скроллбары — штука прекрасная, хоть за 20 лет так и не нашедшая свой путь в стандарты. До сих пор полноценная стилизация возможна только в Blink aka Chromium и WebKit aka Safari.

В Firefox как не работало, так и не работает.

К слову, хорошая статья Ахмада Шадида на тему: https://ishadeed.com/article/custom-scrollbars-css/

Короче, суть бага: если вы решились таки стилизовать скроллбар, то не рассчитывайте, что Safari правильно применит стили по наведению мыши :)

Я, правда, не знаю, кому может прийти в голову менять стили скроллбара по hover.

Раз сработает, два сработает, а на третий — всё, нет. Смотрим видео, собственно.

Решение от Брамуса Ван-Дамма довольно забавное: нужно стриггерить инвалидацию стилей, для чего можно рандомной CSS-переменной присвоить неопределённое значение. Вот так:

.section:hover {
  --force-rerender: ;
}

Странные вайбы такие... IE-шные.

Короче, как будет ссылка на официальный багтрекер — закину.

Upd. Ссылка на багтрекер: https://bugs.webkit.org/show_bug.cgi?id=267575

#css #scrollbar #safari #bug #бородач

#баг дня

Вроде мы все с вами знаем, что CSS — отвечает за представление контента, никак его не модифицируя. И это подтверждается спецификацией во многих местах.

Вот только если ты пойдёшь и скопируешь в Chrome текст, на который наложен text-transfrorm: uppercase, скопируются заглавные буквы!

Но это неправильно: спека.

В общем, в Chrome 127, благодаря разработчикам из Microsoft, это будет исправлено.

Мне нравится путь, которым разрабы Edge выбрали пиар своего браузера: исправление старых багов и работа на девтулзами.

Ну и ссылка на баг: https://chromium-review.googlesource.com/c/chromium/src/+/5399744

Такой же баг присутствует в Safari, Firefox же отрабатывает ок. Думаю, код этой части CSS в Blink довольно старый, потому можно ожидать, что в Safari и WebKit будет бэкпорт.

#bug #chrome #css

#баг дня

Разработчики спецификации:
— Вот вам предложение ввести нативный нестинг в CSS!

Разработчики браузеров:
— Мы сделали вам нативный нестинг в CSS!

Разработчики сайтов:
— Гляди, рендер одного слова занимает пять секунд

Кроме шуток, это действительно интересная проблема. Довольно больно.

Давайте посмотрим на этот пример: https://crisal.io/tmp/lots-of-nesting.html

На моей машине рендерится за 5.4 секунды. MacBook Pro M2 13", Chrome 126.0.6478.63

Safari вылетает и на ноутбуке, и на iPhone.

Firefox показывает кривые данные, но тоже близко к 5 секундам.

Вот ссылка на GitHub issue: https://github.com/w3c/csswg-drafts/issues/2881#issuecomment-1642450622

Проблема нестинга в том, что число комбинаций селектров растёт экспоненциально. И вроде бы понятно, что надо включать мозг, но...

...но делитесь вашими бенчмарками, котаны :)

#css #nesting #bug

#баг дня

Одна из моих любимых фишек инструментов разработчика Google Chrome (aka девтулзов) — это возможность сделать скриншот ноды.

Нужен длинный скриншот страницы? Бахаешь на body или html и сидишь довольный.

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

Но не обошлось без проблем. Ну честное слово, вот же вся страница, на экране. Бери да превращай в картинку. Нет...

Если в вашей ноде есть картинки, добавленные через тег img с атрибутом decoding="async" — они потеряются :(

Вот так вот неожиданно. Видимо кто-то где-то промис не разресолвил :)

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

Но неприятный осадок всё-таки остался.

Сейчас ищу формальное описание бага в багтрекере. Если не найду — придётся заводить.

Демо: https://10web.io/blog/how-to-create-a-blog-on-wordpress/

Просто попробуйте сделать скриншот body, не скролля заранее.

Проверено на Chrome 128.0.6613.120.

В итоге, часть картинок может появиться, а часть — нет.

Вообще, я откровенно не люблю ленивую загрузку картинок и контента. Да, помогает на медленном интернете, но абсолютно мерзко и неудобно на нестабильном соединении. Например, в поезде.

P. S. В Firefox баг тоже имеется.

#chrome #bug #async

#баг дня

Наслаждаетесь экраном MacBook Pro или радуетесь новому wide gamut дисплею от, например, Dell?

Не спешите радоваться, Chome и тут нас подставил!

Обратите внимание на иллюстрацию. На ней — не продублированный текст, а просто пропущенный через SVG-фильтр, который фильтрует цвета и сдвигает контент через матрицу преобразований: https://codepen.io/thebabydino/pen/RwmPZVR

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

Так вот, есть маленькая проблема. На дисплеях с широким покрытием цветового поля Chrome находит зелёный цвет в красном и голубом. Где-то просчитались :) Из-за чего в фильтрах появляются серые полосы.

На Firefox и Safari таких проблем нет.

Чтобы проверить свой дисплей, можно пройти сюда: https://www.wide-gamut.com/test

Чтобы проверить баг, сюда: https://codepen.io/thebabydino/pen/vYqMvzv (должно быть только три чёрные полосы, без серых).

И вот сегодня утром Ана отправила баг в Chromium: https://issues.chromium.org/u/1/issues/373410239?pli=1

Если у вас оно повторяется, напишите, пожалуйста, подробности о своей платформе на трекере 🙏

Новые возможности хардвари — это, конечно, хорошо. Но лучше бы без багов, да.

#color #bug

#баг дня

Если вы тут утром решили развернуть новый проект на Vite, и у вас ничего не вышло, это нормально.

esuild, на котором Vite и основана, в версии 0.24.1 принёс ломающее конфиги изменение.

И на данный момент лучшее решение — запинить зависимость esbuild на 0.24.0: https://github.com/vitejs/vite/issues/19018

Ну или использовать пятую ветку Vite.

Повторяется на всех пакетных менеджерах: и npm, и pnpm и bun и, прости господи, yarn.

Осторожнее там, котаны :)

#vite #esbuild #bug

#баг дня

Посмотрите на иллюстрацию к посту, ничего интересного не замечаете?

А тут происходит ого-го какая драма!

Да, использование новомодных HDR-цветов и описывание их в OKLCH в Chrome на macOS приводит к неожиданным эффектам, будучи применённым на корневую ноду, aka тег HTML.

Правильный цвет тот, что темнее. Откуда я знаю? В Safari бага нет. В FIrefox, кстати, тоже.

А багу в Chrome на macOS тупо два года уже: https://issues.chromium.org/issues/40064153

Ну, бывает.

#oklch #color #bug

#баг дня или история одного апокалипсиса

Знаете, что происходит, если в Firefox ввести в <input type="number"> что-то вроде lol?

Он позволяет.

Да, вы видите эти lol, будто это валидное число. Только вот значение value в DOM превращается в пустую строку. Ну типа «я тебе это показал, но делать с этим ничего не буду». Гениально.

Баг #1398528 в Bugzilla живёт с 2017 года. Проблему признают: Firefox нарушает спецификацию WHATWG, согласно которой input type=number должен принимать только корректные числовые строки. А на деле — буквы, кириллица, эмоджи — всё идёт в бой. Только вот под капотом — пусто. Т.е. ты видишь, что ввёл, но значение не считается валидным. UX? Ну, такое себе.

Почему не фиксят?

Ответ классический: «а что, если у нас локаль с деванагари и арабскими цифрами, и вообще — как различать запятую и точку?». Ну и правда, лучше пусть вводится вся клавиатура, чем разбираться в сепараторах.

А теперь немного цирка из Chrome:

В Chrome <input type="number"> иногда разрешает ввод e, ведь вдруг ты хочешь ввести 1e10 (научную запись). Но если ты просто набрал e, поле становится… валидным. Бинго!

Ещё веселее: 1e- — тоже "нормально", но 1ee — уже нет. Картинку с барабаном вставите сами.

А если ты вводишь 1,5 в локали, где десятичный — это точка, Chrome может забраковать это, а может и нет — зависит от версии, луны и количества кофе у разработчика.

В итоге: у Firefox можно ввести хоть «привет», и он такой: «ну окей, но это не число». Chrome вроде бы фильтрует, но делает это через лунную призму.

Что же мы делаем? Пишем код, блять!

Мораль: в 2025 году проще создать свою валидацию под конкретный случай, чем надеяться, что браузеры когда-нибудь договорятся.
А баг тем временем отмечает 8 лет жизни, всё ещё «NEW», и, судя по комментариям, будет жить

Баг-репорт: https://bugzilla.mozilla.org/show_bug.cgi?id=1398528

Подпишитесь и следите, если вы, как и мы, верите (нет) в чудеса стандартизации.

P. S. тем временем Firefox пробивает дно за дном. В англоязычном интерфейсе выдаёт мне ошибки валидации на финском языке.

P. P. S. я молчу уже о том, что <input type="number"> вообще нахер не нужен и даже вреден: https://t.me/htmlshit/2663

#firefox #bug #input #number

#баг дня

Одна из моих любимых фишек инструментов разработчика Google Chrome или Firefox (aka девтулзов) — это возможность сделать скриншот ноды.

Нужен длинный скриншот страницы? Бахаешь на body или html и сидишь довольный.

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

Но не обошлось без проблем. Ну честное слово, вот же вся страница, на экране. Бери да превращай в картинку. Нет...

Если в вашей ноде есть картинки, добавленные через тег img с атрибутом decoding="async" — они потеряются :(

Вот так вот неожиданно. Видимо кто-то где-то промис не разресолвил :)

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

Но неприятный осадок всё-таки остался.

Сейчас ищу формальное описание бага в багтрекере. Если не найду — придётся заводить.

Демо: https://10web.io/blog/how-to-create-a-blog-on-wordpress/

Просто попробуйте сделать скриншот body, не скролля заранее.

Проверено на Chrome 138.0.7204.184. Столько времени прошло с предыдущей проверки...

В итоге, часть картинок может появиться, а часть — нет.

Вообще, я откровенно не люблю ленивую загрузку картинок и контента. Да, помогает на медленном интернете, но абсолютно мерзко и неудобно на нестабильном соединении. Например, в поезде.

P. S. В Firefox 141 баг тоже имеется.

#chrome #bug #async #бородач

#такое дня

Вы, наверное, ждёте все, что я сообщу о выходе jQuery 4.0?

Ну так не вышла ещё, только RC1: https://blog.jquery.com/2025/08/11/jquery-4-0-0-release-candidate-1/

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

В мире, в котором нет Internet Explorer, всё ещё есть Safari. И не сказать, что это плохой продукт — вроде целевой аудитории-то он даже нравится — но и хорошим не назвать.

И вот что интересно, плохая или, что даже хуже, неочевидная работа Safari и движка WebKit в частности (а точнее говоря, работа движка в конечном продукте интеграции) сформировала целую культуру длинных гневных комментариев!

Вы только посмотрите на пример на иллюстрации! Я уверен, я бы тоже написал нечто подобное (да и писал), если бы наткнулся сам.

Ну то есть суть всей проблемы: WebKit или зумит по двойному тапу, или скроллит, если зум отключён через CSS. И чтобы предотвратить скролл, надо просто объявить использование события двойного клика. Даже отменять поведение по-умолчанию не обязательно.

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

А какая особенность яблочного браузера раздражает вас больше всего, котаны?

#safari #bug #feature