#баг дня
Google весьма знамениты тем, что у них на поток поставлена палочная система.
Если коротко, для достижения следующего грейда, тебе надо внедрить инновацию. Напоминает СССР, не правда ли?
Один сначала вводит инновацию, второй — проводит рационализацию. Оба получили премию.
Вспомним десяток обновлений интерфейса GMail.
Итак, в чём же конкретно проблема: https://issuetracker.google.com/issues/232060574
Есть такой язык и среда — Google Apps Script. Это JavaScript, на самом деле. Используется для написания приложений GSuite (расширения к формам, доксам и таблицам).
У него одновременно поддерживаются две системы развёртывания (деплоя): legacy и текущая.
Мы сидим пока на legacy, поскольку в текущей полно нововведений, несовместимых с жизнью.
Но за каким-то лешим один из сотрудников Google решил провести инновацию и заменил нативные HTML-селекты на самодельные в стиле Material UI.
И естественно, не обошлось без косяка: рендер выпадающей части происходил за пределами самого селекта, через портал. И отступы считались в зависимости от числа элементов в дропдауне.
А у нас их там 2000. Естественно, меню улетело за пределы экрана.
Зачем было трогать легаси-среду? Вопрос риторический.
Браво, Google. Браво. Зато инновация внедрена и премия получена
#google #bug
Google весьма знамениты тем, что у них на поток поставлена палочная система.
Если коротко, для достижения следующего грейда, тебе надо внедрить инновацию. Напоминает СССР, не правда ли?
Один сначала вводит инновацию, второй — проводит рационализацию. Оба получили премию.
Вспомним десяток обновлений интерфейса GMail.
Итак, в чём же конкретно проблема: https://issuetracker.google.com/issues/232060574
Есть такой язык и среда — Google Apps Script. Это JavaScript, на самом деле. Используется для написания приложений GSuite (расширения к формам, доксам и таблицам).
У него одновременно поддерживаются две системы развёртывания (деплоя): legacy и текущая.
Мы сидим пока на legacy, поскольку в текущей полно нововведений, несовместимых с жизнью.
Но за каким-то лешим один из сотрудников Google решил провести инновацию и заменил нативные HTML-селекты на самодельные в стиле Material UI.
И естественно, не обошлось без косяка: рендер выпадающей части происходил за пределами самого селекта, через портал. И отступы считались в зависимости от числа элементов в дропдауне.
А у нас их там 2000. Естественно, меню улетело за пределы экрана.
Зачем было трогать легаси-среду? Вопрос риторический.
Браво, Google. Браво. Зато инновация внедрена и премия получена
#google #bug
👍10
#баг дня
input size=“1” в Firefox слишком широкий. Логика подсказывает нам, что он должен так-то быть в один символ шириной.
Песочница: https://jsbin.com/zavefac/edit?output
Багтрекер: https://bugzilla.mozilla.org/show_bug.cgi?id=1782385
С комментария в приложенном куске кода я в целом в голос прорал: «
Вот и он, кстати: 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
🎉4👍2😁2👎1
#баг дня
input size=“1” в Firefox слишком широкий. Логика подсказывает нам, что он должен так-то быть в один символ шириной.
Песочница: https://jsbin.com/zavefac/edit?output
Багтрекер: https://bugzilla.mozilla.org/show_bug.cgi?id=1782385
С комментария в приложенном куске кода я в целом в голос прорал: «
Вот и он, кстати: 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
😁3❤1👍1
#баг дня
input size=“1” в Firefox слишком широкий. Логика подсказывает нам, что он должен так-то быть в один символ шириной.
Песочница: https://jsbin.com/zavefac/edit?output
Багтрекер: https://bugzilla.mozilla.org/show_bug.cgi?id=1782385
С комментария в приложенном куске кода я в целом в голос прорал: «
Вот и он, кстати: 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 #бородач
🔥4😁4
This media is not supported in your browser
VIEW IN TELEGRAM
#такое дня
Я как-то под новостью о том, что браузеры начали внедрять очередной виджет форм (selectmenu) написал, что браузеры ни один элемент форм не сделали нормально. Собеседник обиделся.
Но даже такой простой элемент как текстовое поле (
Что делает
Дальше веселее.
Эмодзи во всех браузерах считаются по глифам, и только Safari — считает за 1 символ. Ссылка на баг: https://bugs.webkit.org/show_bug.cgi?id=252900
Поведение Safari верно с точки зрения человека, но... браузеры пишут инженеры.
Ещё из проблем — скринридеры никак не оповещают о том, что длина превышена. Сплошное веселье.
В любом случае, не забывайте, что ничему приходящему со стороны браузера в принципе доверять нельзя.
#html #maxlength #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
😁19👍8
#баг дня
Ух, как я люблю такие баги!
Какие — такие?
А такие, которые произошли из-за фич, создававшихся для чего-то хорошего, а теперь используемых чтобы за вами, вот да, тобой конкретно, шпионить!
Итак, встречайте: в Chromium-based браузерах неверно реализован
Этот метод предназначался для проверки доступности загружаемых шрифтов, чтобы можно было не опасаясь подменить ими встроенные.
Но Chrome и иже с ними проверяют этим методом наличие локальных шрифтов. То бишь, установленных у пользователя: https://bugs.chromium.org/p/chromium/issues/detail?id=1416842
Почему это плохо?
Да потому что этот метод активно используется для фингерпринтинга (снятия отпечатков) браузеров и, соответственно, пользователя!
Да, эта дыра лишь одна из многих, позволяющих снять уникальный хэш системы, но одной меньше — уже будет хорошо, согласитесь.
#chrome #bug
Ух, как я люблю такие баги!
Какие — такие?
А такие, которые произошли из-за фич, создававшихся для чего-то хорошего, а теперь используемых чтобы за вами, вот да, тобой конкретно, шпионить!
Итак, встречайте: в Chromium-based браузерах неверно реализован
document.fonts.check()
.Этот метод предназначался для проверки доступности загружаемых шрифтов, чтобы можно было не опасаясь подменить ими встроенные.
Но Chrome и иже с ними проверяют этим методом наличие локальных шрифтов. То бишь, установленных у пользователя: https://bugs.chromium.org/p/chromium/issues/detail?id=1416842
Почему это плохо?
Да потому что этот метод активно используется для фингерпринтинга (снятия отпечатков) браузеров и, соответственно, пользователя!
Да, эта дыра лишь одна из многих, позволяющих снять уникальный хэш системы, но одной меньше — уже будет хорошо, согласитесь.
#chrome #bug
❤4👍3🌚2
#баг дня
Встречали ли вы баги, которым восемь лет?
А вот есть такие! Причём, казалось бы, подобное уже давно должно было быть решено... но нет.
Итак, встречайте: https://bugs.chromium.org/p/chromium/issues/detail?id=507397
Суть бага в следующем: для
Смешное хотите? Microsoft Edge, который ещё на старом движке почти от IE, с этим справлялся без проблем. А вот все современные браузеры так или иначе валились.
Исправлено в грядущем Chrome 116.
#bug #chrome #edge #flex
Встречали ли вы баги, которым восемь лет?
А вот есть такие! Причём, казалось бы, подобное уже давно должно было быть решено... но нет.
Итак, встречайте: 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
😁5🤯5❤2
#баг дня
Итак, проблема известная с десяток лет: при автозаполнении полей форм Хром заливает фон поля цветом. Раньше жёлтым, сейчас — небесно-голубым (во всяком случае, на моём сетапе).
Так что же не так с этим поведением?
Ну, для начала, оно очень непросто отключается. А точнее, не отключается — можно только переопределить. А во-вторых, стоит вам поставить фоновую картинку на ваше поле, для, например, иконки — как Хром и её сотрёт. Вот, посмотрите сами: 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, например:
На протяжении всех этих более 10 лет разработчики Chrome и WebKit вообще активно меняли способы заливки полей, поэтому вариантов обхода можно найти десятки. Вот только абсолютное большинство из них стало или бесполезно, или попросту неудобно.
Поэтому, дамы и господа, остаётся лишь один верный вариант: выносите иконку в отдельный элемент и размещайте поверх поля ввода. Победить это всё, кажется, возможным не представляется. По крайней мере, в рамках разумного 😔
#chrome #autocomplete #bug
Итак, проблема известная с десяток лет: при автозаполнении полей форм Хром заливает фон поля цветом. Раньше жёлтым, сейчас — небесно-голубым (во всяком случае, на моём сетапе).
Так что же не так с этим поведением?
Ну, для начала, оно очень непросто отключается. А точнее, не отключается — можно только переопределить. А во-вторых, стоит вам поставить фоновую картинку на ваше поле, для, например, иконки — как Хром и её сотрёт. Вот, посмотрите сами: 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 {...в кодпене выше так и сделано. Но картинке это никак не поможет, потому что background-image не анимируется.
transition: all 9999s;
transition-delay: 9999s;
}
На протяжении всех этих более 10 лет разработчики Chrome и WebKit вообще активно меняли способы заливки полей, поэтому вариантов обхода можно найти десятки. Вот только абсолютное большинство из них стало или бесполезно, или попросту неудобно.
Поэтому, дамы и господа, остаётся лишь один верный вариант: выносите иконку в отдельный элемент и размещайте поверх поля ввода. Победить это всё, кажется, возможным не представляется. По крайней мере, в рамках разумного 😔
#chrome #autocomplete #bug
😢9👍3
#баг дня
Сегодня 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:
В общем, день был насыщенный.
P. S. По состоянию на 23:00 EET, Google откатывают изменения.
#google #sheets #workspace #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
🤩13👍8❤2🤡2
This media is not supported in your browser
VIEW IN TELEGRAM
#баг дня
Кастомные скроллбары — штука прекрасная, хоть за 20 лет так и не нашедшая свой путь в стандарты. До сих пор полноценная стилизация возможна только в Blink aka Chromium и WebKit aka Safari.
В Firefox как не работало, так и не работает.
К слову, хорошая статья Ахмада Шадида на тему: https://ishadeed.com/article/custom-scrollbars-css/
Короче, суть бага: если вы решились таки стилизовать скроллбар, то не рассчитывайте, что Safari правильно применит стили по наведению мыши :)
Я, правда, не знаю, кому может прийти в голову менять стили скроллбара по hover.
Раз сработает, два сработает, а на третий — всё, нет. Смотрим видео, собственно.
Решение от Брамуса Ван-Дамма довольно забавное: нужно стриггерить инвалидацию стилей, для чего можно рандомной CSS-переменной присвоить неопределённое значение. Вот так:
Странные вайбы такие... 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
👍8❤2
This media is not supported in your browser
VIEW IN TELEGRAM
#баг дня
Кастомные скроллбары — штука прекрасная, хоть за 20 лет так и не нашедшая свой путь в стандарты. До сих пор полноценная стилизация возможна только в Blink aka Chromium и WebKit aka Safari.
В Firefox как не работало, так и не работает.
К слову, хорошая статья Ахмада Шадида на тему: https://ishadeed.com/article/custom-scrollbars-css/
Короче, суть бага: если вы решились таки стилизовать скроллбар, то не рассчитывайте, что Safari правильно применит стили по наведению мыши :)
Я, правда, не знаю, кому может прийти в голову менять стили скроллбара по hover.
Раз сработает, два сработает, а на третий — всё, нет. Смотрим видео, собственно.
Решение от Брамуса Ван-Дамма довольно забавное: нужно стриггерить инвалидацию стилей, для чего можно рандомной CSS-переменной присвоить неопределённое значение. Вот так:
Странные вайбы такие... 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 #бородач
❤16
#баг дня
Вроде мы все с вами знаем, что 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 — отвечает за представление контента, никак его не модифицируя. И это подтверждается спецификацией во многих местах.
Вот только если ты пойдёшь и скопируешь в 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
👍12🤡2
#баг дня
Разработчики спецификации:
— Вот вам предложение ввести нативный нестинг в 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
Разработчики спецификации:
— Вот вам предложение ввести нативный нестинг в 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
👍6🤩1
#баг дня
Одна из моих любимых фишек инструментов разработчика Google Chrome (aka девтулзов) — это возможность сделать скриншот ноды.
Нужен длинный скриншот страницы? Бахаешь на body или html и сидишь довольный.
Нужен лишь кусочек? Не вопрос, выдели нужную ноду мышкой и скриншоть себе на здоровье.
Но не обошлось без проблем. Ну честное слово, вот же вся страница, на экране. Бери да превращай в картинку. Нет...
Если в вашей ноде есть картинки, добавленные через тег img с атрибутом
Вот так вот неожиданно. Видимо кто-то где-то промис не разресолвил :)
Решается проблема удалением атрибута, прямо в девтулзах, и повторным скриншотом. Иногда достаточно и просто убедиться, что все картинки загружены — я пока паттерна не понял.
Но неприятный осадок всё-таки остался.
Сейчас ищу формальное описание бага в багтрекере. Если не найду — придётся заводить.
Демо: https://10web.io/blog/how-to-create-a-blog-on-wordpress/
Просто попробуйте сделать скриншот body, не скролля заранее.
Проверено на Chrome 128.0.6613.120.
В итоге, часть картинок может появиться, а часть — нет.
Вообще, я откровенно не люблю ленивую загрузку картинок и контента. Да, помогает на медленном интернете, но абсолютно мерзко и неудобно на нестабильном соединении. Например, в поезде.
P. S. В Firefox баг тоже имеется.
#chrome #bug #async
Одна из моих любимых фишек инструментов разработчика 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
3👍12❤2🤡2
#баг дня
Наслаждаетесь экраном 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
Наслаждаетесь экраном 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
👍12❤2
#баг дня
Если вы тут утром решили развернуть новый проект на 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
Если вы тут утром решили развернуть новый проект на 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
❤7👍5
#баг дня
Посмотрите на иллюстрацию к посту, ничего интересного не замечаете?
А тут происходит ого-го какая драма!
Да, использование новомодных HDR-цветов и описывание их в OKLCH в Chrome на macOS приводит к неожиданным эффектам, будучи применённым на корневую ноду, aka тег HTML.
Правильный цвет тот, что темнее. Откуда я знаю? В Safari бага нет. В FIrefox, кстати, тоже.
А багу в Chrome на macOS тупо два года уже: https://issues.chromium.org/issues/40064153
Ну, бывает.
#oklch #color #bug
Посмотрите на иллюстрацию к посту, ничего интересного не замечаете?
А тут происходит ого-го какая драма!
Да, использование новомодных HDR-цветов и описывание их в OKLCH в Chrome на macOS приводит к неожиданным эффектам, будучи применённым на корневую ноду, aka тег HTML.
Правильный цвет тот, что темнее. Откуда я знаю? В Safari бага нет. В FIrefox, кстати, тоже.
А багу в Chrome на macOS тупо два года уже: https://issues.chromium.org/issues/40064153
Ну, бывает.
#oklch #color #bug
❤6👍4
#баг дня или история одного апокалипсиса
Знаете, что происходит, если в Firefox ввести в
Он позволяет.
Да, вы видите эти lol, будто это валидное число. Только вот значение value в DOM превращается в пустую строку. Ну типа «я тебе это показал, но делать с этим ничего не буду». Гениально.
Баг #1398528 в Bugzilla живёт с 2017 года. Проблему признают: Firefox нарушает спецификацию WHATWG, согласно которой
Почему не фиксят?
Ответ классический: «а что, если у нас локаль с деванагари и арабскими цифрами, и вообще — как различать запятую и точку?». Ну и правда, лучше пусть вводится вся клавиатура, чем разбираться в сепараторах.
А теперь немного цирка из Chrome:
В Chrome
Ещё веселее: 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
Знаете, что происходит, если в 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
👍14❤9🫡4🤡1
#баг дня
Одна из моих любимых фишек инструментов разработчика Google Chrome или Firefox (aka девтулзов) — это возможность сделать скриншот ноды.
Нужен длинный скриншот страницы? Бахаешь на body или html и сидишь довольный.
Нужен лишь кусочек? Не вопрос, выдели нужную ноду мышкой и скриншоть себе на здоровье.
Но не обошлось без проблем. Ну честное слово, вот же вся страница, на экране. Бери да превращай в картинку. Нет...
Если в вашей ноде есть картинки, добавленные через тег img с атрибутом
Вот так вот неожиданно. Видимо кто-то где-то промис не разресолвил :)
Решается проблема удалением атрибута, прямо в девтулзах, и повторным скриншотом. Иногда достаточно и просто убедиться, что все картинки загружены — я пока паттерна не понял.
Но неприятный осадок всё-таки остался.
Сейчас ищу формальное описание бага в багтрекере. Если не найду — придётся заводить.
Демо: https://10web.io/blog/how-to-create-a-blog-on-wordpress/
Просто попробуйте сделать скриншот body, не скролля заранее.
Проверено на Chrome 138.0.7204.184. Столько времени прошло с предыдущей проверки...
В итоге, часть картинок может появиться, а часть — нет.
Вообще, я откровенно не люблю ленивую загрузку картинок и контента. Да, помогает на медленном интернете, но абсолютно мерзко и неудобно на нестабильном соединении. Например, в поезде.
P. S. В Firefox 141 баг тоже имеется.
#chrome #bug #async #бородач
Одна из моих любимых фишек инструментов разработчика 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 #бородач
❤11
#такое дня
Вы, наверное, ждёте все, что я сообщу о выходе 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
Вы, наверное, ждёте все, что я сообщу о выходе 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
🤬7❤1🤩1