Как работает автозаполнение в браузерах и что важно учитывать веб-разработчику
Время на прочтение
Если человек пользуется автозаполнением в браузере, он ждёт, что сможет быстро заполнять формы на любом сайте, где посчитает нужным. Наладить такой механизм на стороне сайта или веб-приложения несложно, но важно помнить пару вещей — я покажу кейсы, где подходы «в лоб» приводили к непредсказуемым результатам. Чтобы автозаполнение работало эффективно и не нарушало логику, стоит хотя бы примерно представлять, как оно устроено под капотом разных браузеров, которые могут быть у пользователей. Под катом распишу, каким образом движок подставляет данные в формы.
Пароли, карты, личные данные
Есть три основные группы форм, где обычно требуется автозаполнение: личные данные, банковские карты и пароли.
Самая широкая группа — личные данные. К ним относятся имена, адреса, телефоны, дата рождения, пол и всё, что не попадает в группу паролей и банковских карт. У этих данных очень разный формат, поэтому часто браузеры и сайты слабо прорабатывают автозаполнение. В статье я в основном буду говорить про заполнение личных данных.
У банковских карт есть особенности сохранения и подстановки, так как речь идёт про очень чувствительные данные. Допустим, браузеры на основе Chromium, в том числе Яндекс Браузер, запрещают подстановку данных карты на сайтах с небезопасным http-соединением — и требуют https. В целом, обработка данных банковских карт укладывается в общий с личными данными механизм. Я не буду углубляться в особенности автозаполнения банковских карт, но большая часть статьи будет актуальна и для этой группы.
Пароли — тоже чувствительная к безопасности группа данных. Существенная часть всех автозаполнений приходится именно на парольные формы, так что этот сценарий лучше всего проработан браузерами и сайтами. В Chromium механизм сохранения и автозаполнения паролей сильно отличается от аналогичного для личных данных и банковских карт. В этой статье углубляться в парольную специфику мы не станем.
Как это работает?
Чтобы понять, как работает автозаполнение, предположим, что у браузера уже есть сохранённые данные пользователя. К механизму их получения перейдём ниже, а пока рассмотрим вставку значения в поле с момента, когда пользователь нажал на это поле:
Интересно, что само по себе заполнение полей на странице не всегда происходит гладко и без багов. Например, номера телефонов доставляют целый ворох проблем. В России номера начинаются на +7, а люди часто используют вместо этого 8. Браузер может хранить номера в обоих форматах. Проблемы начинаются во время вставки:
Программируйте системы форматирования, выпадающие списки и формы в целом с учётом того, что данные в поле попадут со стороны браузера, а не только в ходе заполнения пользователем.
Так выглядит автозаполнение от выделения поля до вставки в него значения в общем виде. Самый интересный и сложный этап — вычисление подсказки. Разобьём его на несколько тем:
Система типов полей
Тип поля — характеристика, однозначно описывающая данные, которые это поле ожидает в качестве ввода. Типов полей бывает очень много. За их добавление и поддержку отвечают разработчики браузера. Задача типов — однозначно сопоставить поле и соответствующую ему информацию о пользователе.
Примеры типов полей представлены в таблице ниже, а их полный список можно посмотреть в исходниках Chromium.
Автозаполнение на основе типов гарантирует, что в поле окажутся данные только конкретного типа. Допустим, в поле адреса не окажется ФИО. В этом и есть его важное преимущество и отличие от исторических подсказок, которые работают без привязки к типам.
Регулярные выражения — важный инструмент в определении типов. С их помощью сопоставляются значения атрибутов полей с существующими типами. Проще всего объяснить логику работы регулярных выражений с помощью примеров.
Примеры успешных сопоставлений полей и типов:
В примере успешных сопоставлений браузер видит на одном из полей атрибут id со значением first_name. Регулярные выражения сопоставляют это значение с типом NAME_FIRST и таким образом определяют тип поля. Аналогично определяются типы других полей.
Примеры неудавшихся сопоставлений:
Здесь заметно несовершенство подхода с регулярными выражениями. Оно проявляется в атрибутах, по которым невозможно установить тип. Яркий пример — неосмысленные значения полей, как id=”xdia_13″ в примере выше. Регулярные выражения по-разному настроены для разных языков. Поэтому в полях с, казалось бы, идентичными значениями name=”address_mail” и placeholder=”Адрес почты” тип определяется по-разному.
Другая проблема состоит в логически неверном определении типа. Такое случается, если атрибуты недостаточно точно говорят о назначении поля. Допустим, сайт может предложить пользователю заполнить фамилию и имя в двух разных полях. При этом поле с именем отмечено атрибутом name=“name”. В этом случае браузер определит тип поля как NAME_FULL, то есть ФИО, а не NAME_FIRST — только имя, и покажет неверную подсказку или неверно сохранит данные.
Другой подобный пример связан с датами. В форме покупки авиабилета часто встречается поле с датой вылета. Браузер может вычислить тип такого поля как дату рождения пользователя, с неприятными последствиями в виде неверной подсказки или сохранения неверной информации.
Как видим, система, основанная на типах, имеет свои минусы:
Разработчики сайтов могут осмысленно заполнять атрибуты name, placeholder, id и label. Это поможет браузеру верно определить тип поля и улучшить опыт взаимодействия с сайтом.
Исторические подсказки
Система типов полей не всегда работает надёжно. Ей могут помешать неосмысленные значения атрибутов или поле может изначально не попадать ни под один известный тип. В этом случае на помощь приходит ещё один механизм, который вносит свою большую лепту в автозаполнение. Мы называем его историческими подсказками.
Суть механизма состоит в том, что браузер пробует найти в своём хранилище данные для заполняемого поля по его атрибуту name. Если такие данные нашлись, то пользователь увидит подсказку. Если нет, то после заполнения и отправки формы значение поля будет сохранено в виде пары: name: value. Далее браузер сможет использовать эту пару для формирования подсказки, в том числе и на других сайтах, если встретит там поле с уже известным именем. Периодически браузер удаляет записи, которые не использовались определённое время.
Важно отметить, что браузер накладывает некоторые условия на сохранение таких полей. Например, у поля не должно быть значения атрибута autocomplete=“off”. Значение поля сохраняться не будет, и браузер не подскажет его пользователю.
Логично ожидать, что autocomplete=“off” выключит автозаполнение и сохранение информации из поля. По факту это выключит только исторические подсказки, но пользователи могут увидеть другие — основанные на типах! Дело в том, что стандарт HTML даёт весьма нечёткое определение поведения для некоторых значений атрибута.
Атрибут autocomplete
Можно сказать, что огромная машинерия браузера по угадыванию типов полей со всеми недостатками, ошибками и проблемами во многом нужна только потому, что сайты зачастую игнорируют autocomplete. В лучшем случае они используют autocomplete=”on”/”off”.
Значение autocomplete=”on” согласно стандарту подразумевает, что браузер волен сохранять и подсказывать значения как угодно:
Намного интереснее значение autocomplete=”off”. Логично ожидать, что так можно выключить все подсказки для поля, но это носит рекомендательный характер. В стандарте написано, что не следует сохранять данные из поля и предлагать ранее сохранённые значения. В случае обязательных требований стандарт использует must/must not.
Здесь и ниже под
autofill field name
подразумевается значение атрибута autocomplete.
Более того, в стандарте можно найти формулировку, согласно которой браузер позволяет пользователю самому изменить значение autocomplete=”off” и сохранить заполненные данные или автозаполнить поле.
Другая формулировка вообще говорит, что браузер может рассмотреть возможность менять значение autocomplete.
Согласно стандарту мусорные значения типа “none”, “smth” и другие наряду с отсутствием атрибута нужно интерпретировать как поведение по умолчанию, то есть “on”: Processing model, пункт 5. Любопытно, что в этой части Chromium отходит от стандарта и не предлагает подсказки для полей с мусорными значениями. Яндекс Браузер поступает так же. Таким образом, самый надёжный
способ выключить автозаполнение с помощью атрибута — задать ему мусорное значение типа “none”, “smth” или любое другое.
Стандарт HTML весьма расплывчато регламентирует работу автозаполнения. Дисклеймер стандарта в части автозаполнения помечен как «This section is non-normative», из-за чего браузеры вынуждены по-своему его интерпретировать. Поэтому поведение атрибута autocomplete со значением “off” только на первый взгляд кажется неожиданным.
Таким образом, Chromium интерпретирует autocomplete=“off” как отключение исключительно исторических подсказок. Браузер изменит значение “off” на “on”, если смог определить тип поля, и покажет подсказку, основанную на типе.
В то же время стандарт весьма чётко определяет поведение атрибута со значением “on” и особенно с конкретным типом. Получается, что лучший способ управлять автозаполнением на странице — указать тот тип для поля, который максимально соответствует его смыслу.
Отправка формы
Дальше поговорим о том, как браузер получает данные для последующей подстановки. Отправка формы — единственный источник данных о пользователе для браузера. Также браузер даёт пользователям возможность самим сохранить имя, адрес, банковскую карту для оплаты покупок и прочие данные в настройках. Но доля данных, сохранённых таким образом, ничтожно мала по сравнению с отправкой.
В самом простом случае браузер обрабатывает событие submit согласно стандартному поведению отправки формы — это сигнал для сохранения данных. Однако далеко не все формы отправляют такое событие. Многие формы используют нестандартные механизмы отправки данных на сервер. А ещё многие сайты предлагают пользователям заполнять данные в формах, где нет тега form — назовём их бесформенными формами. Это так же мешает браузеру обработать отправку и сохранить данные (ниже обсудим, почему). Всё это вынуждает разработчиков браузера изобретать дополнительные способы наблюдения отправки формы на сайте.
Выделим несколько сценариев отправки с примерами:
В интернете встречаются все перечисленные комбинации, поэтому браузеру важно уметь работать с отправкой всевозможных форм.
Я занимаюсь автозаполнением в Яндекс Браузере на iOS, поэтому примеры ниже будут про эту платформу. По большей части логика сохранения данных и наблюдения за отправкой форм одинакова для всех платформ. Механизм строится по одному и тому же алгоритму и будет интересен вне зависимости от ваших предпочтений в платформе. Но у iOS есть своя специфика, которую важно объяснить прежде, чем мы углубимся в реализацию наблюдения отправки форм.
WebKit
Особенность разработки браузера на iOS состоит в том, что в работе со страницами приходится полагаться на движок WebKit. Он отвечает за рендеринг страницы, хранит данные HTML-формы, позволяет работать с JavaScript и прочее. Desktop и Android работают со страницей с помощью движка Blink. При желании вы можете изменить его код и добиться нужного поведения. На iOS приходится подстраиваться под API, которое предоставляет WebKit. При этом Apple в своём браузере Safari использует так называемое приватное API (методы движка WebKit), которое запрещает использовать его другим разработчикам. К счастью, есть способы обойти ограничение, но они могут не понравиться Apple.
Например, внутри WebKit есть функция, которая сообщает в нативный код браузера информацию об отправке формы. Выглядит так, что это то, что нужно, чтобы отловить submit, и даже Blink работает по аналогии. Но использовать эту функцию нельзя, так как она спрятана в недрах WebKit и не является открытым API. Это лишь одно из ограничений. По сравнению с Blink их очень много.
Chromium
Для обхода ограничений Chromium нашёл «изящный» выход. При загрузке страницы браузер добавляет к ней скрипт, в котором подписывается на события JavaScript. С их помощью браузер отлавливает события отправки форм, изменения DOM-дерева, заполняет поля формы и многое другое. Нативный код в iOS взаимодействует со страницей с помощью JavaScript, в отличие от Android и Desktop. Они взаимодействуют со страницей напрямую из нативного кода благодаря движку Blink.
У подхода со скриптом есть свои минусы:
Скрипт добавляет обработчик на JS-событие submit, и он оповещает нативный код об этом событии. И это единственный способ узнать об отправке формы с личными данными в Chromium для iOS на текущий момент.
Важно отметить, что ситуация с парольными формами обстоит значительно лучше. Для них Chromium обрабатывает поля без тега form и применяет эвристики по определению отправки при отсутствии явного события submit. То есть разработчики браузеров пришли к тому, что странно полагаться только на submit.
Итак, Chromium на iOS не умеет анализировать бесформенные формы с личными данными и оставляет их без внимания, потому что они выпадают из стандартного механизма отправки. Это ведёт к тому, что значительная часть введённых данных не сохраняется, и пользователь не увидит в дальнейшем подсказку, если будет заполнять похожую форму.
В парольных формах с наиболее чувствительной информацией Chromium ориентируется на событие click. Это менее говорящее событие, поэтому браузер вынужден делать дополнительные проверки, чтобы убедиться, что произошла отправка. Суть проверки состоит в том, чтобы понять, что нажатие случилось по кнопке, и это единственная на форме кнопка.
Эти элементы считаются кнопками:
Таким образом, на отправку может указывать нажатие кнопки в том числе без явного JS-события submit.
Бесформенные формы
Отсутствие тега form вносит сложность во многие аспекты механизма автозаполнения, например вставку данных, обработку отправки и сохранение данных.
Основная сложность в работе с бесформенными формами заключается в том, что браузер не может чётко определить границы заполняемой формы. Фактически браузеру приходится анализировать всю страницу с целью собрать все поля ввода и найти кнопки, которые могут вызвать отправку. Ограничение на клик по единственной на форме кнопке для таких форм превращается в ограничение на единственную кнопку на странице.
Немного острее проблема проявляется в single-page applications, где отправиться может малая часть полей, например адрес доставки, но браузер вынужден заодно считать отправленными все остальные поля — почту и телефон, которые могут быть заполненными не полностью.
На удивление, бесформенных форм очень много, и по нашим данным, около трети отправок на Android- и Desktop-версии Яндекс Браузера приходится на такие формы.
Эвристики
У браузера есть ещё несколько козырей в рукаве для того, чтобы обнаружить отправку формы, в том числе по сценарию с отсутствием тега и события submit. Более того, многие формы достаточно
сложны, чтобы браузер не смог определить отправку и в других сценариях с помощью JavaScript, например:
Видно, что эти примеры с точки зрения автозаполнения отличаются лишь наличием тега form. С этими формами мы наблюдаем две проблемы, которые не дают поймать отправку:
Но есть и косвенные признаки отправки формы, на которые браузер умеет реагировать. Как правило, отправка формы вызывает некоторые действия на странице, например:
Итак, можно выделить признаки, которые могут говорить об отправке:
Эти признаки — потенциальные триггеры к отправке. Чтобы она случилась, браузер наблюдает за процессом заполнения формы и фиксирует введённые данные во внутренних структурах. Далее при наступлении одного из трёх триггеров браузер проверяет наличие сохранённой формы с заполненными полями и фиксирует это как отправку.
Главным минусом такого подхода предполагается возможность ложных срабатываний. Ложные срабатывания приведут к тому, что браузер сохранит неверную информацию и будет показывать пользователю нерелевантные подсказки. Может проявиться и проблема быстродействия, потому что эвристики требуют от нативного и JS-кода браузера дополнительной работы.
Chromium не использует эвристики для заполнения личных данных и банковских карт, зато применяет их в случае с паролями.
Итоги
Автозаполнение — настолько же сложная и многогранная тема, как и сам веб. Есть множество вариантов форм, и их разновидности ограничены лишь полётом фантазии разработчиков сайтов. Браузеры подстраиваются и учатся обрабатывать максимально возможное число форм, чтобы облегчить пользователям взаимодействие с сайтами.
Подытожим моменты, на которые браузер обращает внимание. Вот к чему я призываю разработчиков сайтов, чтобы автозаполнение работало эффективно:
Я постарался приоткрыть завесу сложностей вокруг автозаполнения, с которыми сталкиваюсь я и мои коллеги. Надеюсь, команды популярных браузеров и разработчики сайтов будут работать ещё теснее, чтобы делать автозаполнение корректным и удобным.
Можно отключить автозаполнение, если в момент фокусировки в поле поменять у поля значение name на произвольное. А когда пользователь выходит из input, то поменять значение name обратно. В этом случае браузер Хром не выводит подсказок, т.к. каждый раз значение name новое.
Необходимо подключать jquery, а ниже подключить сам скрипт.
Исходник (взял отсюда только код, который генерит значение name) https://github.com/terrylinooo/jquery.disableAutoFill
Что получилось в итоге:
Это сама форма, показываю кусок формы, с полями ввода, для которых отключаю подсказки хрома. Оба инпута имеют класс “only-ru”:
Сам скрипт, который при фокусе генерит произвольное значение для name, а при выходе из фокуса – возвращает значение name обратно, как мне нужно. Можете его улучить, сделать более универсальным:
Введение
Сегодня я расскажу про плагины браузера, которые помогают быстро заполнить поля тестируемой формы. Рассказ также доступен в виде видео. Мой топ-3:
Если авторизоваться в системе, можно добавить новую компанию. Из обязательных полей только «название» и «тип», но есть еще 6 дополнительных — ИНН, ОГРН, КПП, телефон, адрес, сотрудники.
Но эта статья не про автоматизацию, а про плагины. Я уверена, что их сильно больше, чем описано тут. Но чем больше выбор, тем он сложнее. Так что я дам свой топ-3, а дальше уже сами выбирайте))
Ну что, давайте сравнивать плагины!
3 место — Bug magnet
Ссылка — https://bugmagnet.org/ (Chrome или Firefox)
Заполняет поля по одному и с участием человека — нужно выбрать значение, которое хочется подставить.
Но зато в плагине есть куча разных типов полей:
Плагин Bug magnet
Мне больше всего нравятся:
А еще можно просто раскрыть список предлагаемых проверок — и вуаля, у вас уже есть набросок чек-листа для вашего поля!
Авторы пишут, что собрали типичные граничные значения в своих проверочных данных. Да, если присмотреться к Numbers и Text Size, мы увидим там как типовые значения, так и попытки выйти за стандартные границы.
Как использовать
Заполняем название компании кириллицей
* Lorem ipsum — текстовая болванка, применяется в типографике для шаблонов верстки. Там кусок псевдолатыни, начинается как lorem ipsum, оттуда и пошло.
Поле заполнилось кучей русских слов с пробелами:
Результат работы плагина — кириллический текст с пробелами
Отлично. Едем дальше. И НН — это явно число, ищем в numbers.
В ИНН подставим число
Система предлагает разные числа, которые чисто теоретически могут нашу форму сломать. Поэтому в одно поле подставим одно “бажное число”, в другое другое и т.д.
И вот мы заполнили все поля, нажимаем «сохранить». Но увы, получаем ошибку:
Поле ИНН должно состоять из 12 цифр
Ошибка при сохранении карточки
То есть «любое число» здесь не подойдет. А вот ИНН, да еще русского, в плагинчике нету, так что исправляем вручную. И снова пытаемся сохранить, и снова ошибка:
Поле ОГРН должно состоять из 13 цифр
Теперь ошибка в ОГРН
Исправляем, сохраняем. Теперь ошибка в КПП:
Поле КПП должно состоять из 9 символов
Исправляем, сохраняем — ура! Компания создана! Фух, справились! Плагин помог, но не сильно ускорил заполнение.
При создании пользователя плагин уже интереснее, потому что в нем есть имена и email-ы. Правда, имена нерусские, а вот с email-ом bug magnet поможет — подскажет, что именно можно проверить. Какие валидные и невалидные тесты можно провести.
Вот вы можете сходу накидать десяток разных тестов на валидный email? А на невалидный? Нет? Тогда вам точно стоит установить плагинчик. Он как минимум даст вам идеи для чек-листа.
И в этом его мощь. Его можно использовать именно как подсказку «а что еще можно тут проверить?». Даже если вы тестируете мобильное или десктоп приложение, вы просто открываете в вебе любую страничку, хоть google, ставите в любое поле курсор и смотрите, что вообще плагин предлагает проверить для того или иного поля.
Для текстовых полей у плагина много идей:
Заполним все поля разными значениями
Пытаемся сохранить, вылезает ошибка:
Слишком длинное поле name1
Но стойте. Все поля очистились!
При неправильном вводе система очистила ВСЕ поля!
Это косяк разработчика — он обновляет страницу при ошибке, не сохраняя введенные данные. Такое поведение сейчас редко где встретишь, но всякое бывает. А для пользователя это #жизньболь. Да и для тестировщика тоже, если он старался и придумывал для каждого поля какое-то своё значение.
При этом помните, что мы заполняем каждое поле в отдельности, делая 4 действия:
А для email действий будет 5:
Плюсы
1. Подсказывает тесты — что еще можно проверить для числа или email? Может быть как чит-лист для новичков.
Минусы
3. Не учитывает ограничения, наложенные на поле в js — ты ведь сам подбираешь значение под поле. Всё равно надо включать мозг при заполнении полей (а не хочется)
Хочется, чтобы всё заполнялось само и в один клик. Первый пункт самый печальный, поэтому плагин у меня только на третьем месте.
2 место — Web developer toolbar
Ссылка на плагин — http://chrispederick.com/work/web-developer/
Плагин умеет по одной кнопке заполнить все поля формы. Правда, значения будут неуникальные, каждый раз одинаковые — плагин просто берет название поля из html-кода страницы.
Web developer toolbar вообще очень интересный плагинчик, который умеет кучу всякого разного. В рамках этой статьи нас интересует именно автозаполнение форм, поэтому мы будем работать с вкладкой «Forms»
Эта вкладка позволяет вам:
Поэтому плагин настоятельно рекомендую к установке и использованию, если вы тестируете веб-приложения. Пригодится!
После установки плагина все еще быстрее, если используете ровно одну вкладку:
Профит! Все поля заполнены!
Как заполнить поля формы через плагин
Открыли форму, дали плагину задачу «Populate Form Fields» — готово!
Поля формы заполнились, плагин указал, сколько полей заполнил — 7 штук. Причем моментально и сразу все, что сразу делает его удобнее Bug Magnet-а.
За пару кликов заполнили 7 полей!
Пытаемся сохранить — ошибка!
Но увы, от таких ошибок плагин не защищает
Нажимаем F12 — выбираем кнопку слева от «Инспектор» — наводим на поле «Инн».
Ну да, в HTML у этого поля есть атрибут name = “inn”.
А вот если форма — просто набор из текстовых полей, плагин будет шикарен. Хоть 100 полей, мы их заполним в 2 клика!
Однако если страницу обновить и снова заполнить, плагин подставит ровно те же самые значение! Так что быстренько наклепать 10 разных пользователей не получится, увы.
На этот раз за 2 клика мы заполнили сразу 19 полей, круто!
19 полей за 2 клика!
Пытаемся сохранить — увы, слишком много символов в имени собачки:
Пытаемся добавить ещё одного нового пользователя по тому же принципу:
Такое имя в базе уже есть
Исправили имя, сохраняем — и емейл такой уже существует. Исправили — сохранился! Уф, то есть чтобы создать второго и последующего пользователя, количество действий уже больше:
За 1 кнопку заполняешь сразу все поля — хоть 7, хоть 27, хоть 107!
1. Значения всегда одинаковые — каждый раз заполняет одними и теми же значениями
2. Плагин не учитывает тип поля (кроме email)
1 место — Fake Filler
О плагине
Ссылка на плагин — https://fakefiller.com/ (а вот расширение для Chrome).
Раньше назывался Form Filler.
По одной кнопке заполняет все поля формы, причем рандомными значениями! В этом его огромный плюс перед web developer toolbar — то, что значения каждый раз разные. Не нужно дополнительных телодвижений, чтобы создать уникальные данные.
Что он умеет? Плагин:
После установки плагина достаточно нажать на его иконку
Как использовать fake filler
И всё! Все поля заполнены!
Открыли форму, нажали кнопку плагина — профит!
По одной кнопке заполнили все поля!
Обратите внимание, что поля заполнены рандомными значениями. Это не просто название поля из кода html, а что-то похожее на правду. Попробуем снова тыкнуть на иконку форм-филлера — и поля теперь заполнены другими значениями!
Если тыкать на кнопку несколько раз, значения будут обновляться!
Можете хоть 10 раз тыкать на кнопку, значения будут разные. А, значит, мы не напоремся на проблему «ФИО с таким именем в базе уже есть».
Попробуем сохранить — ошибка:
Поле ИНН должно состоять из 10 цифр
Но ошибок всё равно не избежать
То есть снова те же проблемы, данные заполняются наобум, а не по типу полей. Правда, телефон плагин подставил похожим на правду, так что какие-то поля он все-таки знает.
Заполняем плагином, корректируем вручную нужные поля.
Тыкает на плагин — он подставляет вполне нормальные (хоть и не русские) имя и емейл. То есть какие-то типовые поля он понимает. Дату из календаря также выбрал.
Плагин осмысленно подставил имя, емейл, даже заполнил дату!
Но при попытке сохранить получаем ошибку, что превышена длина поля name1
Это странно, в HTML-коде мы видим maxlenght = 10 на этом поле, а плагин вроде должен уметь читать этот атрибут. Но, видимо, срабатывает далеко не всегда. Может, он читает этот атрибут только если он единственный на поле, кто знает.
В любом случае, приходится “дорабатывать” форму ручками. Снова тык-тык плагин, подправили name1 и пытаемся сохранить. В любом случае это будет быстрее, чем с web developer toolbar, так как не надо менять имя и емейл на уникальные значения.
1. За 1 кнопку заполняешь сразу все поля — хоть 7, хоть 27, хоть 107!
2. Каждый раз разные значения! — значит, можно легко наклепать 10 разных пользователей / карточек товара / чего-то ещё.
3. Умеет заполнять дропдауны, чек-боксы и радио-баттоны.
4. Учитывает maxlenght — по крайней мере местами, с этим плагином я намного реже огребаю “поле слишком длинное”, чем с остальными.
1. Нерусские данные
2. Не знает такие типы, как ИНН, ОГРН.
Итого
Мы обсудили 3 плагина
Bug magnet — плагин для исследовательского тестирования. Мы обращаемся к нему за идеями для тестов и поисков вдохновения при составлении чек-листов. Его можно использовать для автозаполнения полей, но придется заполнять каждое поле по отдельности.
А если мы хотим заполнить сразу все, мы используем либо web developer toolbar (вкладка forms), либо fake filler.
А вы какие плагины любите для автозаполнения полей?
Если зайти в любой магазин приложений, будто то App Store или Google Play, можно обнаружить множество программ для управления паролями. Безусловно, лучше пользоваться лишь одним, сделав его основным по умолчанию для автозаполнения паролей на устройстве. К сожалению, сторонние решения не всегда гибкие и удобные по сравнению со стандартным менеджером паролей, поэтому есть смысл пользоваться стандартным приложением от Google. Сегодня расскажем, как настроить автозаполнение паролей на Android так, чтобы не повторять чужих ошибок при их хранении и не потерять их из виду.
Как правильно настроить автозаполнение на Андроид? Все, что нужно знать
Автозаполнение паролей на Андроид
Чтобы устройство могло автоматически заполнять формы на сайтах и в приложениях, например, данными кредитных карт, номера телефонов и аккаунтов, вам пригодится автозаполнение. Эта функция делает всё за вас, помогая избежать ввода вручную. У Google есть собственный менеджер паролей, который наверняка вам знаком еще по Google Chrome: пароли, сохраненные в менеджере паролей Google, хранятся в облаке, поэтому к ним можно получить доступ сразу на нескольких устройствах.
Автозаполнение выручает, когда не помнишь пароль от аккаунта
Если в настройках включено автозаполнение, то вы можете получить доступ к паролям из приложений и сайтов: система сама позволит выбрать данные учетной записи и не вводить их вручную. Не сработает, правда, если пароль вы сменили и не обновили. Зато очень удобно, если не помните надежный пароль, подобранный автоматически со случайными символами и цифрами.
Не работает автозаполнение паролей на Андроид
Кроме того, автозаполнение паролей Google синхронизируется с другими менеджерами и извлекает их оттуда. Работает, например, с LastPass и 1Password. Правда, иногда сторонние приложения могут работать некорректно: я пользовался LastPass долгое время, но в последнее время оно перестало предлагать пароли для автозаполнения. При входе на сайт открывалось LastPass, в котором нужно было авторизоваться, отвлекая от дел. Связь между менеджером паролей и системой пропала — не помогало ни обновление, ни переустановка.
Стандартный менеджер паролей сильно выручает, когда сторонние аналоги не работают
Несмотря на то, какое приложение хотите использовать для сохранения паролей, вы всегда можете включить его по умолчанию на Android. Изменить настройки автозаполнения очень просто. Вот, как это можно сделать на смартфонах Pixel и других устройствах под управлением Google Android.
Отключите автозаполнение на Android следующим образом
Автозаполнение паролей на Самсунг
Назначить нужный менеджер автозаполнения вы также можете на смартфонах Samsung Galaxy. Делается это похожим образом.
А вот так можно сменить менеджер паролей на Samsung
После этого приложение предложит вам выбрать, хотите ли вы автоматически заполнять пароли при входе в приложение. Но, как показывает практика, стандартная служба работает намного лучше.
Microsoft могла выпустить первый складной телефон еще 12 лет назад, но передумала
Как отключить автозаполнение на Андроид
Иногда бывает так, что автозаполнение на телефоне нужно отключить: например, сервисы не оплачиваете, поменялись данные или попросту хотите делать это вручную. Отключить автозаполнение паролей можно следующим образом.
Отключение автозаполнение паролей — самая болезненная штука
🔥 Удаленными приложениями из Google Play вы можете пользоваться в нашем удобном каталоге
Многие предпочитают хранить данные карт в телефоне и пользоваться быстрой вставкой при оплате, когда это необходимо, а не вводить данные вручную. Отключите автозаполнение банковских карт, если не хотите рисковать: делается это следующим образом.
Автозаполнение карт лучше отключить, чтобы не разбрасываться платежными данными где попало
Отключить автозаполнение карт точно нужно, потому что сайты самостоятельно смогут проверять данные карточек до того, как вы подтвердите их вставку. Это опасно, ведь в Chrome сохраняются не только номера, но и CVV-коды. Эти данные также не стоит предоставлять несмотря на коды верификации, приходящие при подтверждении платежа через СМС.
Если с настройкой автозаполнения все понятно, то вот насчет яркости экрана возникают вопросы: в нашей статье рассказали о том, как ее настраивать, как выбрать идеальный уровень подсветки экрана и нужно ли использовать автояркость.