Кнопка «Назад» на сайте: как проверить, что клиент не теряет товары и заполненные поля

Возврат в каталог стирает выбор

Из карточки товара покупатель нажимает «Назад» и попадает в начало каталога без выбранных фильтров. Исправление такого поведения стоит принимать по сохранённому выбору, позиции в списке и возможности продолжить покупку: изменение адреса страницы проверяет лишь часть этого пути. Ниже разберём магазин с фильтрами, корзиной и формой заказа.

Переход назад восстанавливает прошлый шаг, но разные сведения живут в разных местах. Условия фильтра могут находиться в адресе страницы, положение списка — в памяти вкладки, товары корзины — на сервере. Заполненные поля ещё могут быть не отправлены. Поэтому одна удачная демонстрация кнопки не подтверждает работу всего пути. Каждую часть принимают по её назначению.

Что покупатель ожидает увидеть

Возврат полезен, когда человек продолжает выбор. Если он открыл товар из середины отфильтрованного списка, то разумно вернуть тот же набор и близкое положение просмотра, чтобы не заставлять повторять поиск среди уже отброшенных вариантов и заново находить место остановки.

Ожидаемый возврат сначала описывают словами: какие фильтры остаются, где открывается список и как ведёт себя уже добавленный товар. Затем специалист выбирает, как это обеспечить при обычных переходах или обновлении содержимого без полной загрузки страницы. Для покупателя различие технологий незаметно, пока сохраняется понятная последовательность действий. В задании полезно отдельно назвать сортировку и положение просмотра, потому что сохранённый фильтр ещё может вернуть человека к началу длинного списка. Приёмка повторяет путь от выбранного места к карточке и обратно, а не ограничивается совпадением адресов.

Ошибка или намеренное действие

Кнопка «В каталог» на странице и кнопка браузера «Назад» имеют разный смысл. Первая может вести в определённый раздел, вторая возвращает по истории посещения, поэтому требовать от них совершенно одинакового результата стоит только тогда, когда это прямо соответствует замыслу магазина.

Я предпочитаю сохранять выбор при возврате браузером и делать сброс фильтров отдельным видимым действием. Иначе сайт принимает решение за человека и стирает уже выполненную работу. Важна и кнопка «Вперёд». После возврата в список она должна вести к понятному следующему состоянию, а не открывать случайную карточку или пустой экран. Такая проверка обнаруживает ошибки, которые одиночное нажатие назад не показывает.

Адрес страницы и история переходов

Когда сайт обновляет каталог без перезагрузки, браузеру нужно сообщать о значимых шагах. MDN описывает для этого History API: pushState добавляет запись истории, replaceState изменяет текущую, а событие popstate помогает обработать переход к другой записи, например после нажатия «Назад» или «Вперёд». Заказчику достаточно знать последствия.

Новый адрес не сохраняет корзину. История переходов и данные покупки — разные части работы, которые специалист связывает так, чтобы возврат на предыдущую страницу не отменял уже подтверждённые действия покупателя.

Слишком много шагов тоже неудобно

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

Для фильтра, которым нужно делиться, лучше согласовать воспроизводимый адрес. Скопированная ссылка открывает тот же подбор в новой вкладке, если это входит в требования магазина. Такая проверка дополняет возврат назад, но не совпадает с ним. Новая вкладка не обязана иметь прежнее положение прокрутки. Зато выбранные параметры из ссылки должны дать объяснимый результат.

Первая страница и прямой вход

Особенно полезно начать маршрут с прямого открытия каталога. В документации MDN отдельно разбирается начальная запись истории: она может не содержать состояния, которое приложение добавляет позже, поэтому возврат к первому экрану требует внимания разработчика и отдельного испытания.

Для замечания не нужен термин pushState. Достаточно записи: открыт адрес каталога, применён фильтр, показана карточка, после возврата исчезает выбор. Приложите начальный адрес и последовательность действий. Если ошибка возникает только после прямого входа из рекламы, это существенная деталь. Она отличает проблему начального состояния от обычного перехода внутри сайта.

Устранять сбой блокировкой кнопки назад — плохое решение. Покупатель теряет привычное управление браузером и может закрыть страницу целиком, тогда как восстановление истории позволяет ему спокойно продолжить выбор в уже знакомой последовательности.

Корзина после возврата может устареть

Браузер способен восстановить прежнюю страницу очень быстро, вместе с её видимым состоянием. На web.dev это описано как back/forward cache, или bfcache, но восстановленный экран может показывать старое количество товаров или старую цену, если покупка успела измениться в другом месте. Быстрый возврат требует актуализации.

Это не обычная загрузка. Документация различает событие pageshow и его признак persisted, по которому разработчик определяет возвращение страницы из такого кеша. Заказчику важен результат: после возврата корзина и доступность товаров соответствуют текущим данным магазина. Старое изображение страницы не должно разрешать покупку по уже недействующим сведениям. Особое внимание нужно последней кнопке оформления.

Сохранить выбор, обновить факты

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

В тесте можно добавить товар, перейти в оформление, вернуться и изменить количество перед следующим проходом. Для более сложного сценария специалист организует изменение корзины во второй вкладке или изменение доступности товара на тестовых данных. Главное — заранее описать ожидаемый итог. Возврат на прежний экран не должен возвращать в оплату удалённые товары.

После выхода из аккаунта

Личные сведения требуют отдельного сценария. На общем устройстве возврат назад после выхода не должен снова открывать доступ к истории и действиям прежнего пользователя, поэтому разработчик проверяет состояние доступа даже тогда, когда браузер сохранил состояние предыдущей страницы.

Web.dev отдельно обращает внимание на такой риск при восстановлении из bfcache. Это основание испытать выход и возврат, а не повод отключить быстрое восстановление у всех страниц магазина. Для каталога и личного кабинета возможны разные действия. Специалист подбирает их по данным, которые показывает экран. Заказчик принимает итог от лица гостя после завершения сеанса.

Заполненная форма и повторная отправка

Возврат к форме нужен, чтобы исправить или дополнить данные. При этом ещё не отправленные поля, созданный заказ и подтверждённая оплата находятся на разных этапах, поэтому сохранение текста в браузере не должно создавать новый заказ или повторно выполнять платёжное действие, когда человек просто перемещается по истории. Возврат не равен новой покупке.

Черновик формы

Сохранение имени, контакта и выбранной доставки удобно в пределах текущего оформления, если пользователь может увидеть и изменить значения. Срок и место хранения обсуждают отдельно. В MDN для sessionStorage описано хранение данных в пределах сеанса вкладки, включая сохранение при перезагрузке. Это один из технических инструментов. Сам выбор инструмента не определяет, какие персональные сведения допустимо в нём оставлять.

Требование к сохранению формы лучше записать по группам данных: что остаётся после возврата, что исчезает после выхода и как экран ведёт себя на общем устройстве. Формула «сохранять всё навсегда» смешивает удобство текущей покупки с длительным хранением личных сведений. Для адреса, комментария и контакта команда задаёт нужный срок и доступного получателя. Платёжные данные рассматривают отдельно по правилам выбранной системы оплаты. Приёмка затем проверяет не наличие какой-либо памяти в браузере, а возможность продолжить заказ без неожиданного раскрытия сведений следующему пользователю устройства.

После отправки

Готовый заказ имеет свой номер. Если покупатель возвращается к оформлению и снова нажимает кнопку, магазин должен отличить повтор того же действия от создания действительно нового заказа, а результат показать так, чтобы человек понял, принят ли первый запрос.

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

Ошибка и исправление

Если неверен телефон, остальные сведения стоит сохранить. Это лучше, чем возвращать покупателя к пустой форме, потому что ошибка относится к одному значению и не даёт оснований стирать адрес, способ получения и комментарий. Подробный выбор необходимых строк рассмотрен в материале о полях заказа в Битриксе. Здесь важно проверить, переживают ли эти строки возврат и повторный ввод. Тест заканчивается созданием ровно того заказа, который покупатель намеревался оформить.

Маршрут для самостоятельного испытания

Пройдите выбор товара с телефона и компьютера, используя именно кнопки браузера, а затем повторите действие жестом возврата там, где устройство его поддерживает. Записывайте начальную страницу, шаги и изменившиеся сведения, чтобы специалист мог воспроизвести ошибку без доступа к личному устройству покупателя. Скриншота финального экрана мало.

Каталог и карточка

Сначала примените фильтр и сортировку, прокрутите список и откройте товар. После возврата сопоставьте параметры, набор товаров и положение просмотра. Нажмите «Вперёд». Следом откройте исходную ссылку в новой вкладке. Эти действия проверяют разные ожидания, поэтому результаты записывают отдельно.

• Фильтры сохранились при возврате из карточки.
• Сортировка и страница списка не сброшены без причины.
• Покупатель видит место, с которого удобно продолжить выбор.
• Переход вперёд открывает ожидаемую карточку.
• Прямая ссылка воспроизводит те параметры, которые магазин обещает сохранять в адресе.

Корзина и оформление

Дальше добавьте товар и заполните часть формы на тестовой среде. Вернитесь к корзине, измените количество и снова откройте оформление. Сверьте поля и сумму. Ошибка в одном значении не должна очищать остальные строки. После успешной отправки повторите возврат и убедитесь, что второго заказа без нового намерения не появилось.

Испытание проводят без реальных списаний. Подрядчик включает тестовый режим оплаты и безопасную доставку уведомлений, а сотрудник магазина сверяет созданные записи, чтобы приёмка не отправляла настоящие обращения, письма или заказы в рабочую обработку.

Как выглядит полезное замечание

Вместо «Назад работает странно» укажите, что после открытия карточки из отфильтрованного каталога исчезают выбранные параметры, хотя адрес остаётся прежним. Приложите устройство, браузер и точную последовательность. Разработчику будет проще отличить потерю состояния от устаревшего кеша или ошибки восстановления начального экрана. Исправление проверяют тем же маршрутом: после возврата покупатель сразу видит сохранённый выбор без дополнительной перезагрузки.

Для обсуждения доработки сайта достаточно такого протокола и списка ожидаемых состояний. Он позволяет оценить работу без изучения браузерного API. У магазина появляется повторяемый сценарий контроля. Его стоит проходить после изменений каталога, корзины и авторизации, потому что каждая из этих частей участвует в одном покупательском пути.