#баг дня

Google весьма знамениты тем, что у них на поток поставлена палочная система.

Если коротко, для достижения следующего грейда, тебе надо внедрить инновацию. Напоминает СССР, не правда ли?

Один сначала вводит инновацию, второй — проводит рационализацию. Оба получили премию.

Вспомним десяток обновлений интерфейса GMail.

Итак, в чём же конкретно проблема: https://issuetracker.google.com/issues/232060574

Есть такой язык и среда — Google Apps Script. Это JavaScript, на самом деле. Используется для написания приложений GSuite (расширения к формам, доксам и таблицам).

У него одновременно поддерживаются две системы развёртывания (деплоя): legacy и текущая.

Мы сидим пока на legacy, поскольку в текущей полно нововведений, несовместимых с жизнью.

Но за каким-то лешим один из сотрудников Google решил провести инновацию и заменил нативные HTML-селекты на самодельные в стиле Material UI.

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

А у нас их там 2000. Естественно, меню улетело за пределы экрана.

Зачем было трогать легаси-среду? Вопрос риторический.

Браво, Google. Браво. Зато инновация внедрена и премия получена

#google #bug

#баг дня

input size=“1” в Firefox слишком широкий. Логика подсказывает нам, что он должен так-то быть в один символ шириной.

Песочница: https://jsbin.com/zavefac/edit?output

Багтрекер: https://bugzilla.mozilla.org/show_bug.cgi?id=1782385

С комментария в приложенном куске кода я в целом в голос прорал: «To better match IE»…

Вот и он, кстати: https://searchfox.org/mozilla-central/rev/92e8568bbe7c8bf64f7a8ee958291877d960d7d8/layout/forms/nsTextControlFrame.cpp#209-232

Вроде как для моноширинных шрифтов все отрабатывает как надо. Но что-то пошло не так.

#firefox #bug

#баг дня

input size=“1” в Firefox слишком широкий. Логика подсказывает нам, что он должен так-то быть в один символ шириной.

Песочница: https://jsbin.com/zavefac/edit?output

Багтрекер: https://bugzilla.mozilla.org/show_bug.cgi?id=1782385

С комментария в приложенном куске кода я в целом в голос прорал: «To better match IE»…

Вот и он, кстати: https://searchfox.org/mozilla-central/rev/92e8568bbe7c8bf64f7a8ee958291877d960d7d8/layout/forms/nsTextControlFrame.cpp#209-232

Вроде как для моноширинных шрифтов все отрабатывает как надо. Но что-то пошло не так.

#firefox #bug

#баг дня

input size=“1” в Firefox слишком широкий. Логика подсказывает нам, что он должен так-то быть в один символ шириной.

Песочница: https://jsbin.com/zavefac/edit?output

Багтрекер: https://bugzilla.mozilla.org/show_bug.cgi?id=1782385

С комментария в приложенном куске кода я в целом в голос прорал: «To better match IE»…

Вот и он, кстати: https://searchfox.org/mozilla-central/rev/92e8568bbe7c8bf64f7a8ee958291877d960d7d8/layout/forms/nsTextControlFrame.cpp#209-232

Вроде как для моноширинных шрифтов все отрабатывает как надо. Но что-то пошло не так.

#firefox #bug #бородач

#такое дня

Я как-то под новостью о том, что браузеры начали внедрять очередной виджет форм (selectmenu) написал, что браузеры ни один элемент форм не сделали нормально. Собеседник обиделся.

Но даже такой простой элемент как текстовое поле (input type="text") не обошёлся без проблем. Мы уже знаем, что size="1" неправильно работает в Firefox потому что IE. А теперь ещё интересного: атрибуту maxlength нельзя слепо доверять.

Что делает maxlength? Не даёт ввести в поле символов больше, чем указано. Если вставите — браузер обрежет (уже звоночек).

Дальше веселее.

Эмодзи во всех браузерах считаются по глифам, и только Safari — считает за 1 символ. Ссылка на баг: https://bugs.webkit.org/show_bug.cgi?id=252900

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

Ещё из проблем — скринридеры никак не оповещают о том, что длина превышена. Сплошное веселье.

В любом случае, не забывайте, что ничему приходящему со стороны браузера в принципе доверять нельзя.

#html #maxlength #bug

#баг дня

Ух, как я люблю такие баги!

Какие — такие?

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

Итак, встречайте: в Chromium-based браузерах неверно реализован document.fonts.check().

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

Но Chrome и иже с ними проверяют этим методом наличие локальных шрифтов. То бишь, установленных у пользователя: https://bugs.chromium.org/p/chromium/issues/detail?id=1416842

Почему это плохо?

Да потому что этот метод активно используется для фингерпринтинга (снятия отпечатков) браузеров и, соответственно, пользователя!

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

#chrome #bug

#баг дня

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

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

Итак, встречайте: 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