Вы по-тихоньку верстаете очередной дизайн и в этот раз вы решили попробовать 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) поддерживают голосование. Я не уверен, что разработчики принимают во внимание рейтинг багрепортов, но если да, то высокий рейтинг способствует более быстрому устранению найденной ошибки.
Разные движки, разные багтрекеры
У каждого браузера есть свой багтрекер, предназначенный для публикации найденных пользователями ошибок:Обратите внимание на то, что Safari и Chrome базируются на одном и том же движке Webkit, так что если баг проявляется в обоих браузерах, то писать нужно именно на багтрекер Webkit.
Все багтрекеры публичны, кроме одного: Opera Wizard. Вы можете отправить отчет об ошибке в Opera, но доступа к отправленным другими пользователями отчетам, их обсуждению и прогрессу исправления, вы не получите. Доступ ко всем этим вещам есть только у волонтеров Opera и работников компании. Волонтером можно стать только по приглашению (с заключением соглашения о неразглашении), причем получить заветное приглашение — задача не из легких. Отсылайте все ошибки, какие найдете, и возможно, вам улыбнется удача.
Создание хорошего багрепорта
Самая важная часть хорошего отчета — это очищенный от ненужного мусора код. Это самая сложная часть, остальное займет не более пяти минут.Хорошее краткое описание
Краткое описание — вторая по счету самая важная вещь в отчете. Необходимо найти идеальный баланс, краткое описание бага должно быть не слишком длинным и не слишком коротким. Вот хороший пример:Background image disappears when body{display:table} is used (common CSS hack for correct centering + scrolling in Firefox)К тому же, можно добавить к краткому описанию теги, которые помогут другим пользователям найти ваш отчет быстро и безболезненно. К примеру, можно в конце приписать операционную систему, забагованный параметр и в принципе все, что душе угодно, главное — теги должны иметь непосредственное отношение к багу.
Основная информация
Тут, в принципе, все очень просто. Дайте ссылку на очищенный код, поделитесь результатами своих экспериментов с багами, расскажите свое личное мнение о возможной причине проявления ошибки. Главное, меньше болтовни, больше дела. Не надо рассказывать о том, что перед обнаружением бага вы ковырялись в носу. Старайтесь избегать любой информации, не являющейся полезной в исследовании ошибки.Чего делать не следует
Никогда, НИКОГДА не пихайте информацию о нескольких разных багах в один отчет. Это создает путаницу и дополнительные препятствия на пути к устранению проблемы, это раз.Два, я могу понять, что некоторые ошибки могут сильно раздражать, мешать и тормозить рабочий процесс, но грубость вам не поможет. Оставайтесь спокойными, особенно в обсуждении отчета, а мысли типа «Я просто не могу поверить, что эти придурки не могут понять о каком баге идет речь!» оставляйте при себе.
А что дальше?
В какой-то момент, обычно через пару дней или недель, кто-нибудь изменит статус вашего отчета. Если вам сообщили, что этот отчет — дубль, не расстраивайтесь, такое с каждым случается. Если же вашему отчету дали статус «Подтверждено», это хороший знак, говорящий о том, что вы действительно нашли новый баг. Со временем статус изменится на «Передано», это значит, что ваш отчет был передан непосредственно разработчикам браузера и они наверняка уже скоро исправят эту ошибку. Когда ваш отчет определят в категорию «Исправлено» — поздравте себя, вы внесли свою лепту в разработку браузера.Оригинал статьи: Help The Community: Report Browser Bugs
Автор: Lea Verou
Дата публикации: 07.09.11
Этот текст распространяется на условиях лицензии «Creative Commons Attribution-NonCommercial-ShareAlike 3.0».
Вы можете копировать, редактировать и использовать не в коммерческих целях этот текст при обязательном указании авторства и сохранении оригинальной лицензии.
