Что такое баг браузера
Вы по-тихоньку верстаете очередной дизайн и в этот раз вы решили попробовать CSS3 и HTML5, ведь нынче эти новые спецификации вполне поддерживаются большинством современных браузеров. Вы настрочили уже приличное количество кода, время от времени подумывая о том, как же упрощают вашу работу новые технологии и вдруг вам в голову взбрело ненадолго остановиться и проверить работу странички в других браузерах. Вы уже начинаете нервничать, ведь козе понятно — подобную проверку надо было проводить на гораздо более ранних стадиях. Вы запускаете все браузеры, какие у вас есть, и шепчите своему компьютеру «Пожалуйста, работай». Браузер А, все работает. Вы улыбаетесь, чувствуете облегчение. Браузер B и все тоже отлично. Вы расплываетесь в улыбке и у вас поднимается настроение. Браузер C… «FUUUUUUUUUUUUU~!»
Возможно вы будете удивлены, но далеко не всегда подобная ситуация является ошибкой веб-разработчика. В условиях нынешней гонки вооружения на рынке веб-браузеров и невероятного прогресса среди веб-технологий и спецификаций, создатели браузеров вводят новые фичи в спешке, время от времени даже без должного тестирования. CSS3 и HTML5 гораздо сложнее устроены, чем их предшественники, количество возможных комбинаций новых фич зашкаливает, что, зачастую, и является причиной бага: две (или более) штуки не были протестированы вместе. В результате разработчики браузеров отводят устранению багов гораздо больше времени, чем должны.
Почему я должен сообщать о багах разработчикам?
Если этого не будете делать вы, то возможно, что этого не сделает никто. Возможно, тот баг, что вы нашли, настолько редкий, что больше никто на него никогда не наткнется. Или наткнется, но не будет знать, как сообщить о нем разработчику или подумает, что дело вовсе не в браузере. К тому же, если вы использовали новые технологии в своем коде таким образом, что проявился баг, то с большой вероятностью вы снова таким же образом на него наткнетесь, так что скорое исправление ошибки и в ваших интересах тоже. И в конце концов, вы поможете тысячам других веб-разработчиков избежать того облома, который был испытан вами.
Возможно вы думаете, что сообщать о багах бессмысленно, потому как на их исправление уйдут годы, и при этом еще больше времени потребуется пользователям, чтобы обновиться до исправленной версии браузера. Открою вам тайну: у всех браузеров, кроме IE, все обстоит гораздо лучше. В наше время, пользователи Firefox, Opera, Safari и Chrome обновляются до новых версий очень быстро, во многом благодаря разработчиком браузеров — надоедающие окна с предложениями обновиться, пропаганда новых версий, а то и полностью автоматическое тихое обновление без ведома пользователя (речь идет о Chrome). Баги исправляются весьма быстро, особенно те, о которых было должным образом доложено разработчикам.
Находим то, что вызывает баг
Первый шаг к хорошему репорту — поиск причины проблемы. Другими словами, нам надо свести проблемный код к минимуму, что бы не утруждать разработчиков ненужным мусором. Если баг касается рендера страниц, то вам обязательно надо будет приложить к репорту код, вызывающий проблему. И даже если вы ошиблись, и проблема не с браузером, то вы хотя бы будете знать об этом, а опыт никогда не бывает лишним.
- Скопируйте куда-нибудь свой проект в таком виде, в каком вы нашли баг;
- Откройте код и начните постепенно удалять содержимое используемых на странице CSS и JS файлов. В конце концов после очередного удаления вы обнаружите, что баг пропал. В таком случае, верните удаленный фрагмент кода назад и попробуйте избавиться от всего остального так, что бы баг остался. В редких случаях, удаление CSS и JS может оказаться бессмысленным, это значит, что скорее всего, проблема с связана с HTML;
- Теперь вам необходимо найти конкретный блок кода, который является причиной проявления бага. Медленно и аккуратно заключайте куски кода в комментарии пока проблема не исчезнет. Лично мне гораздо легче делать это бинарным методом: сначала, закомментируйте примерно половину кода; если баг остался, то удалите закомментированный код, закомментируйте половину оставшегося и повторите процедуру. К сожалению, чистка кода от лишнего мусора может затянуться — бывали ситуации, когда баг проявлялся только при комбинировании определенного кода определенным образом;
- Перенесите оставшийся CSS и JS код из файлов в HTML-страницу, заключив его в теги style или script . Это сделает репорт еще аккуратнее;
- Теперь пришло время удалить ненужный HTML-код. Первым делом, избавьтесь от любой идентифицирующей или личной информации, затем удалите все остальное. К примеру, если баг связан с работой CSS — удалите все элементы, к которым не применен стиль, вызывающий баг;
- Смените содержимое, заключенное в title , на что-нибудь связанное с багом.
Теперь у вас есть чистый, читаемый код, который вызывает ту или иную ошибку, но первым делом вам следует проверить его. Вы уверены, что он валиден? Разработчики браузеров не могут учитывать ошибки веб-кодеров и делать так, что бы их продукт нормально обрабатывал код с ошибками. Как вариант, воспользуйтесь онлайн-валидаторами.
- Попробуйте внести незначительные изменения в код, таким образом вы сможете узнать масштабы бага. К примеру, если вы обнаружили, что браузер неправильно обрабатывает border-radius: 50% , посмотрите, проявится ли баг с другим значением (к примеру, 40%). Даже если баг проявляться не будет, лучше всего упомянуть о своих экспериментах в отчете, чтобы разработчикам не пришлось их повторять;
- Попробуйте внести в код изменения, которые не должны на практике ничего менять, к примеру, переконвертируйте все значения из em в px . Опять же, независимо от результата упомяните о проделанной работе в отчете.
Даже если у вас нет времени на обработку забагованного кода, сделайте багрепорт. Плохой отчет лучше, чем ничего. В этом случае обработкой вашего кода будут заниматься разработчики, но помните, что им приходится то же самое с огромным количеством других багрепортов, поэтому от публикации отчета до исправления ошибки пройдет гораздо больше времени.
Стоит ли сообщать о баге?
- На самом деле то, что вы принимали за баг, таковым не является;
- Баг уже был устранен в последней nightly-версии;
- Об этом баге уже был сделан отчет кем-то другим.
Пройдемся по всем трем причинам.
Баг или не баг?
В большинстве случаев, если вы почистили код от мусора и оставили только то, что вызывает баг, можно очень легко определить, является ли наблюдаемая ошибка последствием работы разработчиков браузера
Как-то давно я обнаружил, что outline-color: invert работает не во всех браузерах. Если быть точным, речь шла о Firefox, Safari и Chrome. Перечисленные браузеры не игнорировали этот код, но обрабатывали его так, будто я использовал currentColor . Разумеется, я почистил код, изолируя ошибку, и создал отчеты на багтрекерах всех перечисленных браузеров. Через некоторое время мне сообщили, что в спецификации есть сноска, говорящая о том, что разработчики браузеров вправе обрабатывать этот параметр таким образом, так что оказалось, что багом тут и не пахло. Мораль заключается в том, что перед публикацией отчета нужно внимательно прочитать спецификацию якобы забагованных параметров. К тому же, узнавая подобные особенности вы набираете ценный опыт как разработчик.
Был и другой случай, я листал спецификации CSS3 и наткнулся на описание работы границ, где было написано, что в CSS3 можно использовать проценты для указания их ширины. Разумеется, у меня зачесались руки и я решил эту фичу протестировать, однако ни один современный браузер не рендерил код в соответствии с прочитанной мною спецификацией. Я оформил и опубликовал багрепорт, на который мне ответили, мол, эта фича была удалена из самой последней, dev-версии (т.е. неопубликованной) спецификаций. Мораль этой истории проста: когда сверяете баг со спецификациями, вместо опубликованной читайте dev-версию.
Разумеется, бывает, что веб-разработчики, как и все люди, тупят. И оказывается, что баг не является багом не из-за недочитанных спецификаций или ошибки в коде, а просто из-за невнимательности. Помню свою фрустрацию, когда я не мог заставить работать один JS-код, при том, что даже ошибок никаких не вываливалось. В итоге я обнаружил, что недавно отключил JavaScript в браузере и забыл включить обратно.
Помню самый унизительный случай на своей практике. Я оформил багрепорт и опубликовал его на багтрекер Opera, в котором описывалась ситуация, когда pointer-events не работали, будучи заключенными в select и в итоге меня деликатно проинформировали о том, что pointer-events вообще не поддерживаются этим браузером.
В редких случаях, баг действительно является багом, но к конкретному браузеру он отношения не имеет. Спецификации языков разметки тоже иногда содержат ошибки. О подобных багах следует отправлять отчеты на сайты разработчиков той или иной спецификации (в случае с CSS, вам нужен W3C bug tracker). Даже в таком экзотическом случае, перечисленные выше инструкции все еще применимы.
Была ли исправлена ошибка в последнем Nightly-билде?
Был ли уже сделан подобный багрепорт?
Если после внимательного перечитывания спецификаций и установки ночного билда, вы все еще уверены, что перед вами баг — следует прочесать багтрекер на предмет наличия багрепорта, описывающего вашу проблему. Убедитесь, что поисковик по багтрекеру выдает все результаты, включая неподтвержденные и исправленные баги.
Если отчет не нашелся, попробуйте изменить поисковый запрос, использовать синонимы, попробуйте продумать все возможные названия искомых отчетов.
Обнаружили, что кто-то опередил вас с отчетом? Не спешите уходить, некоторые багтрекеры (такие как Bugzilla) поддерживают голосование. Я не уверен, что разработчики принимают во внимание рейтинг багрепортов, но если да, то высокий рейтинг способствует более быстрому устранению найденной ошибки.
Разные движки, разные багтрекеры
Создание хорошего багрепорта
Самая важная часть хорошего отчета — это очищенный от ненужного мусора код. Это самая сложная часть, остальное займет не более пяти минут.
Хорошее краткое описание
Краткое описание — вторая по счету самая важная вещь в отчете. Необходимо найти идеальный баланс, краткое описание бага должно быть не слишком длинным и не слишком коротким. Вот хороший пример:
Background image disappears when body is used (common CSS hack for correct centering + scrolling in Firefox)
К тому же, можно добавить к краткому описанию теги, которые помогут другим пользователям найти ваш отчет быстро и безболезненно. К примеру, можно в конце приписать операционную систему, забагованный параметр и в принципе все, что душе угодно, главное — теги должны иметь непосредственное отношение к багу.
Основная информация
Тут, в принципе, все очень просто. Дайте ссылку на очищенный код, поделитесь результатами своих экспериментов с багами, расскажите свое личное мнение о возможной причине проявления ошибки. Главное, меньше болтовни, больше дела. Не надо рассказывать о том, что перед обнаружением бага вы ковырялись в носу. Старайтесь избегать любой информации, не являющейся полезной в исследовании ошибки.
Чего делать не следует
Никогда, НИКОГДА не пихайте информацию о нескольких разных багах в один отчет. Это создает путаницу и дополнительные препятствия на пути к устранению проблемы, это раз.
Два, я могу понять, что некоторые ошибки могут сильно раздражать, мешать и тормозить рабочий процесс, но грубость вам не поможет. Оставайтесь спокойными, особенно в обсуждении отчета, а мысли типа «Я просто не могу поверить, что эти придурки не могут понять о каком баге идет речь!» оставляйте при себе.
А что дальше?
В какой-то момент, обычно через пару дней или недель, кто-нибудь изменит статус вашего отчета. Если вам сообщили, что этот отчет — дубль, не расстраивайтесь, такое с каждым случается. Если же вашему отчету дали статус «Подтверждено», это хороший знак, говорящий о том, что вы действительно нашли новый баг. Со временем статус изменится на «Передано», это значит, что ваш отчет был передан непосредственно разработчикам браузера и они наверняка уже скоро исправят эту ошибку. Когда ваш отчет определят в категорию «Исправлено» — поздравте себя, вы внесли свою лепту в разработку браузера.
Этот текст распространяется на условиях лицензии «Creative Commons Attribution-NonCommercial-ShareAlike 3.0».
Вы можете копировать, редактировать и использовать не в коммерческих целях этот текст при обязательном указании авторства и сохранении оригинальной лицензии.
Сталкивались ли вы с багами в реализации спецификаций HTML и CSS в современных браузерах?
Опрос в Твиттере
Читаете ли вы спецификации HTML/CSS, чтобы найти истину?
Опрос в Твиттере
Опрос «The Ultimate CSS Survey»
Какой браузер не прав?
«Designing Flexible, Maintainable Pie Charts With CSS And SVG»
1 2
2 🤔
1 2
1 🤔
Спецификация изменилась, правильное поведение сейчас в Safari и Edge. Многострочный контейнер — тот, которому задан flex-wrap: wrap , даже если строка в контейнере одна.
1 2
1
1 🤔
1 2
1 🤔
Спецификация изменилась.
Safari не использует технику pre-multiplied sRGBA.
Мораль
- не делить браузеры на «хороших» или «плохих»;
- обращать внимание на различия между отображениями браузеров;
- читать спецификацию, обращать внимание на раздел изменений;
- следить за публикациями сообщества, например, Flexbugs.
Немного про тестирование в браузерах
- сервисы: Browserstack, Saucelabs; ; : EdgeHTML на Windows 10 для Mac;
- или друг/коллега с нужной операционной системой на компьютере.
Баг найден.
Что дальше?
Проверяем баг в «ночной» сборке браузера
Опрос в Твиттере
Опрос «The Ultimate CSS Survey»
Опрос «The Ultimate CSS Survey»
Сообщество, посвященное киберпанку и посткиберпанку.
Будем рады видеть арты на тему киберпанка, посты про разработку игр этой тематики, и все, что связано с киберпанком в реальной жизни.
Пикабу в мессенджерах
Активные сообщества
Тенденции
Зато потом кайф, когда закрываешь их все разом
Баг в Chrome И Firefox позволял подменить URL, используя арабские символы!
Независимый исследователь Рафай Балоч (Rafay Baloch) обнаружил баг, суммарно принесший ему $5000 по bug bounty программам Google и Mozilla. Исследователь рассказал, что подменить URL в адресной строке браузера можно просто использовав арабскую письменность или символы любого другого языка, в котором чтение и письменность осуществляются справа налево.
В своем блоге Балоч пишет, что проблема очень проста и связана с тем, как браузеры обрабатывают ссылки, в которых сочетаются символы арабского языка или иврита (которые записываются и читаются справа налево), и обычная латиница, знаки и цифры. Некоторые браузеры в таком случае меняют части ссылок местами, создавая у пользователя иллюзию, что он находится совсем не на том сайте, который открыт в окне браузера.
В настоящий момент проблема устранена в Firefox для Android, а Google обещает представить исправление для Chrome в сентябре 2016 года. Однако исследователь пишет, что такой же баг присутствует и в других браузерах. Так как патчей еще нет, Балоч не раскрывает их названий.
P.S.-Если все кинулись тестировать другие браузеры на наличие данного бага, то не забудьте пожалуйста отписаться в данном посте. Остальным участникам сообщества и пользователям пикабу будет интересно. )))))
Тенденции
Зато потом кайф, когда закрываешь их все разом
Баг в Chrome И Firefox позволял подменить URL, используя арабские символы!
Независимый исследователь Рафай Балоч (Rafay Baloch) обнаружил баг, суммарно принесший ему $5000 по bug bounty программам Google и Mozilla. Исследователь рассказал, что подменить URL в адресной строке браузера можно просто использовав арабскую письменность или символы любого другого языка, в котором чтение и письменность осуществляются справа налево.
В своем блоге Балоч пишет, что проблема очень проста и связана с тем, как браузеры обрабатывают ссылки, в которых сочетаются символы арабского языка или иврита (которые записываются и читаются справа налево), и обычная латиница, знаки и цифры. Некоторые браузеры в таком случае меняют части ссылок местами, создавая у пользователя иллюзию, что он находится совсем не на том сайте, который открыт в окне браузера.
В настоящий момент проблема устранена в Firefox для Android, а Google обещает представить исправление для Chrome в сентябре 2016 года. Однако исследователь пишет, что такой же баг присутствует и в других браузерах. Так как патчей еще нет, Балоч не раскрывает их названий.
P.S.-Если все кинулись тестировать другие браузеры на наличие данного бага, то не забудьте пожалуйста отписаться в данном посте. Остальным участникам сообщества и пользователям пикабу будет интересно. )))))
Задачами сообщества являются поддержка, разъяснение и консультирование Пикабушников по правовым вопросам. Сообщество также осуществляет развлекательную и просветительскую функции путем публикации материалов тематической направленности и юмористического содержания.
Пикабу в мессенджерах
Активные сообщества
Тенденции
Зато потом кайф, когда закрываешь их все разом
Баг в Chrome И Firefox позволял подменить URL, используя арабские символы!
Независимый исследователь Рафай Балоч (Rafay Baloch) обнаружил баг, суммарно принесший ему $5000 по bug bounty программам Google и Mozilla. Исследователь рассказал, что подменить URL в адресной строке браузера можно просто использовав арабскую письменность или символы любого другого языка, в котором чтение и письменность осуществляются справа налево.
В своем блоге Балоч пишет, что проблема очень проста и связана с тем, как браузеры обрабатывают ссылки, в которых сочетаются символы арабского языка или иврита (которые записываются и читаются справа налево), и обычная латиница, знаки и цифры. Некоторые браузеры в таком случае меняют части ссылок местами, создавая у пользователя иллюзию, что он находится совсем не на том сайте, который открыт в окне браузера.
В настоящий момент проблема устранена в Firefox для Android, а Google обещает представить исправление для Chrome в сентябре 2016 года. Однако исследователь пишет, что такой же баг присутствует и в других браузерах. Так как патчей еще нет, Балоч не раскрывает их названий.
P.S.-Если все кинулись тестировать другие браузеры на наличие данного бага, то не забудьте пожалуйста отписаться в данном посте. Остальным участникам сообщества и пользователям пикабу будет интересно. )))))
Читайте также: