#баг дня

Если вы когда-нибудь пытались повторить подобие раскладки masonry на grid, вы вполне себе могли столкнуться с косяком: после некоторого числа строк, все элементы начинают накладываться друг на друга.

Вот вполне себе пример: https://jsfiddle.net/cdysL3rm/2/

Для предотвращения утечек памяти, число строк в гридах было ограничено 1000.

Подобные виды имитации Masonry больше напоминают хак, так что этот лимит очень легко преодолеть. В моём случае – уже на пятидесяти изображениях.

Сейчас этот лимит подняли.

Так вот, багу — больше 4 лет: https://bugs.chromium.org/p/chromium/issues/detail?id=688640

И его наконец-то исправили! Не прошло и пяти лет :)

Правда, до выхода ещё надо немного подождать.

#chrome #grid #bug

#баг дня

Смотрите, что нам Брамус Ван Дамм принёс на своём бельгийском хвосте: https://codepen.io/bramus/pen/RwgXxJv

Вам не показалось, это именно что добавление теней на прокручиваемый контейнер.

Так вот, там присутствует решение крайне неприятного бага: https://bugs.webkit.org/show_bug.cgi?id=181048

Фоны с background-attachment: local не перерисовываются на мобильном Safari до тех пор, пока не масштабируешь экран.

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

#safari #bug

#баг дня

Давно багов не было! Встречайте: в Chrome 96 на macOS Monterey символы переноса отображаются квадратиками: https://codepen.io/bramus/pen/57d328f32cbc657a3d7a3f4a59506e02

Баг официально зарегистрирован: https://bugs.chromium.org/p/chromium/issues/detail?id=1267606

Обходится просто:

html {
    -webkit-hyphenate-character: '-';
}

Исправлено в Chrome 98.

#chrome #bug

#баг дня

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