JavaScript перенаправления (location.href) ломает кнопку Назад, если не используется setTimeout () - PullRequest
5 голосов
/ 17 сентября 2010

Я только что натолкнулся на странное поведение в Firefox 3.6 / Mac. Я подозреваю, что это обычное поведение Firefox.

Я создал две очень простые тестовые страницы, которые изменяют свойство window.location.href для перехода на новый URL:

Если вы попробуете следующее с любым файлом:

  • Открыть новую / пустую вкладку браузера.
  • Вставьте URL и нажмите «Enter».

Вы заметите одно различие между ними: по первой ссылке браузер отключил кнопку «Назад»; с помощью второго он включен и работает так, как я ожидал.

Единственное различие между этими двумя сценариями состоит в том, что последний устанавливает время ожидания в одну секунду перед изменением window.location.href.

Я не знаю, почему это происходит, и я пытаюсь добиться поведения второго скрипта (где кнопка «Назад» продолжает работать, как и ожидалось), не вызывая задержки для пользователя.

Мое лучшее предположение заключается в том, что, возможно, Firefox обрабатывает немедленное «перенаправление», устанавливая window.location.href так же, как и метод window.location.replace(), поскольку я думаю, что разработчики обычно используют первое, когда они намеревались использовать второе. Возможно использование setTimeout, так как это приводит к асинхронному выполнению кода, побеждает это поведение. Может ли это быть так?

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

Спасибо!

Ответы [ 2 ]

2 голосов
/ 18 января 2011

Вы правы, полагая, что настройка location.href во время загрузки страницы рассматривается как замена. На самом деле существует два отдельных поведения.

Во-первых, установка location.href из скрипта, запущенного в результате анализа тега, всегда интерпретируется как замена. Это было реализовано для отражения поведения Netscape 4 и впоследствии настроено .

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

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

1 голос
/ 27 октября 2010

Мое лучшее предположение заключается в том, что, возможно, Firefox обрабатывает немедленное «перенаправление», устанавливая window.location.href так же, как и метод window.location.replace (), поскольку я думаю, что разработчики обычно используют первое, когда предназначен для использования последнего. Возможно, использование setTimeout, так как это приводит к асинхронному выполнению кода, побеждает это поведение. Может ли это быть так?

Я сказал Ваше предположение верно, но теперь, когда я смотрю, в спецификации HTML5 (по ссылке на самая релевантная страница, так как трудно сослаться на отсутствие требования).

...