Скрипт блокировки кнопки назад в браузере
Примечание: статья посвящена обзору проблемы неработающей кнопки «назад» в браузере при использовании AJAX-методов для передачи содержания страниц от сервера к клиенту. В статье рассматриваются основные принципы работы AJAX и возможные пути решения заявленной проблемы. Курсивом даны мои комментарии.
Эта статья является первой из ряда материалов (вторая статья посвящена работе с закладками), направленных на устранение части критики, которую адресуют сейчас AJAX, и предоставляющих обзор полезных методов, которые помогут сделать ваши приложения и веб-страницы, использующие технику AJAX, немного лучше.
Суть проблемы
С самого начала в основе Веба лежала возможность поставить гиперссылку с одной страницы на другую. Ссылки между страницами была первично двунаправленными: это означало, что переход по ссылке со страницы А на страницу Б никаким образом не мог предотвратить ни переход по ссылке обратно на страницу А, ни использование кнопки «назад» в браузере. Цепочка таких страниц представляет собой историю посещения в браузере, с каждой из них связан уникальный URL. Если представить это с технической стороны, то такая цепочка реализуется в виде стека. В дальнейшем я буду использовать термин «горизонтальная» ссылка для обозначения связи между элементами такого стека.
Рисунок 1. Горизонтальные ссылки
Рисунок 2. Вертикальная ссылка между вторым URL'ом и сервером
Веб-сайт и веб-приложение
Подход, который стоит использовать для решения этой проблемы, напрямую зависит от того, что вы разрабатываете: веб-сайт или веб-приложение. Иногда тяжело разделить эти два понятия, но обычно веб-приложение можно отличить по следующим свойствам:
- Перед использованием требуется авторизация
- Серьезная работа с пользовательскими сессиями
- Процесс взаимодействия пользователя с приложением имеет вполне определенное начало и конец
В качестве примера веб-сайта можно рассмотреть Yahoo! Finance и E*TRADE — в качестве веб-приложения. С точки зрения пользователя я могу сказать, что не всегда возможно провести четкую границу между этими двумя типами. Однако, веб-разработчикам стоит с самого начала определиться, что же они собираются разрабатывать: сайт или приложения? Если вам это понять, то можно задать простой вопрос: в отсутствии интернета чем лучше всего описывается ваша разработка: это набор Word'овых документов или же настольное приложение? Рассматривайте веб-приложения наравне с настольными с той лишь разницей, что первым еще требуется браузер для нормальной работы. Другой вопрос, который можно себе задать, звучит так: «Вашей главной целью будет предоставление информации или обеспечение функциональности?».
Первое решение: не злоупотребляйте вертикальными ссылками
Если вы собираетесь создать веб-сайт для публичного доступа, я бы советовал вам использовать AJAX только в случаях крайней необходимости (не злоупотреблять им). Возможно, будет требоваться изменение URL'а страницы, чтобы обновить ее всю, но при этом, я полагаю, иделогия правильной работы кнопки «назад» в браузере будет соблюдена. Помните, что не все вызовы AJAX сильно связаны с вертикальными ссылками (прим.: как я понимаю, автор имеет в виду прежде всего изменение каких-либо малых частей страницы при неизменном основном содержимом).
Легче всего просто не принимать во внимание неработоспособность кнопки «назад» в браузере, но полностью этим пренебрегать нельзя. Вместо того, чтобы создавать целостное приложение, использующее большое количество вертикальных ссылок и привязанное к единственному URL'у, создайте некоторое количество горизонтальных ссылок в тех местах, где это действительно требуется. Другими словами, используйте горизонтальные ссылки для разделения частей вашего приложения, например, таким образом, как это делается в бумажной литературе (книга делится на части и главы). Используя разумную комбинацию традиционных горизонтальных ссылок с вертикальными, можно добиться баланса мощи AJAX и возможности использовать функционал перемещения по истории браузера.
Прим.: в качестве примера, пожалуй, можно привести некоторое количество современных сайтов, на которых AJAX используется только для предоставления некоторых дополнительных возможностей, в частности, это Хабрахабр и механизм голосования/добавления комментариев.
Второе решение: используйте специальную AJAX-библиотеку
Прим.: ниже сгруппированы основные методы создание псевдо-горизонтальных ссылок, я постарался дополнить их известными мне примерами, расширив список статьи-первоистоника.
-
Прим.: суть решения: при каждом вызове AJAX к URL'у страницы в качестве якоря добавляется текущий номер элемента в стеке «истории», фактически, просто увеличивающиеся числа. При нажатии кнопки «назад» в браузере, URL страницы меняется на предыдущий. Каждые 100 (200, 400, 1000) миллисекунд страница проверяет, не изменился ли у нее якорь в URL'е, если якорь изменился, то осуществляется подгрузка данных, соответствующих текущему якорю (=элементу в стеке «истории»).
Подход Brad Neuberg'а, эта библиотека пытается быть максимально кроссбраузерной без лишнего усложнения кода. Хорошо, что она доступна под BSD opensource лицензией. Brad опубликовал пошаговую инструкцию создания этой библиотеки, равно как и онлайн-демо.
Plex — AJAX framework с открытым кодом, который поддерживает очень много возможностей, в том числе, и эмуляцию кнопки «назад» в браузере.
Dojo — еще один AJAX framework с открытым кодом, обеспечивающий некоторую AJAX функциональность и эмуляцию кнопки «назад» в браузере.
Не могу также не упомянуть про неплохую обзорную статью Vladimira Kelmana, в которой обсуждаются часть вышеупомянутых решений.
Решение третье: обеспечьте пользователям удобную альтернативу кнопки «назад»
Традиционно, кнопка «назад» служила для реализации концепции: «Верните меня туда, откуда я пришел» Однако, при нажатии на нее многие пользователи, на самом деле, подразумевают «отмените то, что я только что сделал». Чтобы избавить их от сооблазна воспользоваться кнопкой «обратно» не по назначению, можно создать кнопки с функциями «Отменить» или «Шаг назад» в вашем веб-приложении, использующем AJAX. Например, если вы разрабатываете в Вебе расширенный текстовый редактор, создайте кнопку «Отменить», которая предотвратит потерю пользователями целого документа при неверном нажатии кнопки «назад» в браузере.
Однако, самим плохим решением из всех, которые я видел, является создание альтернативной кнопки «назад» в пределах самой веб-страницы, используя AJAX-методы. Многие пользователи с трудом смогли привыкнуть к границе между браузером и веб-страницей, смогли понять, где кончается браузер и начинается, собственно, сама страница. Нет никакой необходимости усиливать их неудобства. Ведь вы не можете гарантировать, что те пользователи, которые легко с этим справились, смогут привыкнуть еще к одной «инновации» и изменят свои привычки ради вашего сайта. Обеспечить пользователей альтернативной навигацией и функционалом будет вполне достаточно, но никак не создавать эту кнопку заново.
В заключении, если вы все же ограничиваете функционал стандартной истории в браузере при создании веб-приложения, пожалуйста, поставьте пользователей об этом в известность тем или иным способом. AJAX не является первым методом, который ограничивает этот функционал, и, скорее всего, пользователи впервые узнают об этом тоже не от вас. (Есть еще апплеты, Flash и eCommerce приложения, которые могут снять с кредитной карточки сумму еще раз, если нажать кнопку «назад» в браузере.) Вес ответственности, который вы, в конечном счете, возложите на пользователя за его действия на сайте, будет зависеть от вашей корпоративной культуры, но почему бы не сделать его чуточку легче?
Спасибо всем, что читал, читает и будет читать мои переводы и статьи. Заранее хочу поблагодарить всех тех, что укажет на фактические неточности или ошибки в статье, а может быть, даст ссылки на дополнительную информацию.
How to disable browser's BACK Button (across browsers)?
+1 Because although I agree that disabling the browsers back button is 'bad practice', I see no reason for downvoting the question itself, answering and explaining why is the way to go imo.
Why are we being hostile to this question? For all we know, the person asking this question already knows that this is poor usability practice but are just following requirements, or maybe they just want to learn something. Why don't we just pretend this is a hypothetical question, and answer how we would do it IF we were to do that sort of thing?
Some things should never be done, regardless of any desire to do them. Having a non-negotiable requirement for this instantly says that the requirements were set by people with no business setting them, which is a much bigger problem.
20 Answers 20
Do not disable expected browser behaviour.
Make your pages handle the possibility of users going back a page or two; don't try to cripple their software.
Thanks dude, the thing is that if you're building an AJAX app, the cost-benefit tradeoff between disabling the back button, or going through your app and working out the appropriate back action for each and every possible scenario, may tend towards disabling the back button being the more attractive option of the two.
I would agree with Jonathan, especially with the flood of redirect malware adverts that are currently flooding the internet, they already abuse the alert system to make leaving their pages difficult without giving them the ability to actually lock you on to their page
I came up with a little hack that disables the back button using JavaScript. I checked it on chrome 10, firefox 3.6 and IE9:
What is it doing?
The problem with this is that the page is scrolling to the top every 50 ms. If you have a form larger than window height, this will make it impossible to fill inn the form values.
Thanks very much. This is super useful for a JavaScript based particularly interactive page I have, where scrolling left and right is part of the mechanic. This helps eliminate the problem of the scroll gesture on Mac OS X taking users "back" a page by accident (all to easy to do if they are already scrolled all the way).
Others have taken the approach to say "don't do this" but that doesn't really answer the poster's question. Let's just assume that everyone knows this is a bad idea, but we are curious about how it's done anyway.
You cannot disable the back button on a user's browser, but you can make it so that your application breaks (displays an error message, requiring the user to start over) if the user goes back.
One approach I have seen for doing this is to pass a token on every URL within the application, and within every form. The token is regenerated on every page, and once the user loads a new page any tokens from previous pages are invalidated.
When the user loads a page, the page will only show if the correct token (which was given to all links/forms on the previous page) was passed to it.
The online banking application my bank provides is like this. If you use the back button at all, no more links will work and no more page reloads can be made - instead you see a notice telling you that you cannot go back, and you have to start over.
I am doing an online quiz application in PHP. I want to restrict the user from going back in an exam.
I have tried the following script, but it stops my timer.
What should I do?
The timer is stored in file cdtimer.js.
I have the exam timer which takes a duration for the exam from a MySQL value. The timer starts accordingly, but it stops when I put the code in for disabling the back button. What is my problem?
35 Answers 35
There are numerous reasons why disabling the back button will not really work. Your best bet is to warn the user:
This page does list a number of ways you could try to disable the back button, but none are guaranteed:
it works but, This shows the alert on all the menu buttons as well. when it is going to change page, it shows the alert. Can we just fix it to the back button only
It is generally a bad idea overriding the default behavior of the web browser. A client-side script does not have the sufficient privilege to do this for security reasons.
There are a few similar questions asked as well,
You can-not actually disable the browser back button. However, you can do magic using your logic to prevent the user from navigating back which will create an impression like it is disabled. Here is how - check out the following snippet.
This is in pure JavaScript, so it would work in most of the browsers. It would also disable the backspace key, but that key will work normally inside input fields and textarea .
Recommended Setup:
Place this snippet in a separate script and include it on a page where you want this behavior. In the current setup it will execute the onload event of the DOM which is the ideal entry point for this code.
It was tested and verified in the following browsers,
yes true, it will work, but i if i have to recall something from memory when i had this at first place. the flow was not working properly in chrome as in other browsers. Chrome returned the empty location.hash initially so it made me to do it like this. There could be more improvement to this but 50 ms just once didn't cost me much so i leave it there.
I created a .js file as recommended and included the js file in my code using the following: But I can still perform a back (using Safari). What am I missing? This library was added in the same fashion as other libraries I use, so the include is good.
I came across this, needing a solution which worked correctly and "nicely" on a variety of browsers, including Mobile Safari (iOS 9 at time of posting). None of the solutions were quite right. I offer the following (tested on Internet Explorer 11, Firefox, Chrome, and Safari):
Note the following:
- history.forward() (my old solution) does not work on Mobile Safari --- it seems to do nothing (i.e., the user can still go back). history.pushState() does work on all of them.
- the third argument to history.pushState() is a url. Solutions which pass a string like 'no-back-button' or 'pagename' seem to work OK, until you then try a Refresh/Reload on the page, at which point a "Page not found" error is generated when the browser tries to locate a page with that as its URL. (The browser is also likely to include that string in the address bar when on the page, which is ugly.) location.href should be used for the URL.
- the second argument to history.pushState() is a title. Looking around the web most places say it is "not used", and all the solutions here pass null for that. However, in Mobile Safari at least, that puts the page's URL into the history dropdown the user can access. But when it adds an entry for a page visit normally, it puts in its title, which is preferable. So passing document.title for that results in the same behaviour.
Perfect solution for modern browsers. I have combined with @Rohit416 answer to support older browser just using condition typeof (history.pushState) === "function" work smooth.
In Chrome 79.0.3945.130 this isn't working for me. I implemented exactly as above and I'm able to go back by clicking the Back button. When I hold the Back button and select any item in the history, it's true that I'm blocked. But a quick click on the Back button takes me right back to the previous page.
This solution does not work in Chrome. Works in other browsers. I don't know why it no longer works in Chrome. It is a dubious practice, which leads me to believe Chrome is trying to nullify code like this.
Genius! I used this to prevent accidental trigger of Back button when user hits Backspace (on disabled/readonly fields, for example) in a web app where back/forward didn't really make sense anyway. Confirmed disables back and forward functionality (tho not the buttons themselves), including context menu option; verified in IE8 thru IE11, Chrome & FF.
This worked for me also, but on Firefox it seems to break the window.history.back() function. We want to prevent the users clicking on the browser back button, but in some cases we provide our own back button on the page. Is there any way to make it work?
This doesn't work for me. I'm using Chrome version 55 on Windows 10. I put the script in several places (start of header, end of body, etc.) and I can still use the back button to go back to the previous page.
For restricting the browser back event:
i just tested it using Windows 10 OS on the following browsers ( works great ) Chrome Version 74.0.3729.108 (Official Build) (64-bit) Chrome Canary Version 76.0.3780.0 (Official Build) canary (32-bit) Chromium Version 66.0.3355.0 (Developer Build) (64-bit) Firefox 66.0.3 (64-bit) EDGE IE 11 Safari 5.1.7
@TarıkSeyceri because this only works on browsers that a) support the history API b) the page is actually using the history API to manage state
This code will disable the back button for modern browsers which support the HTML5 History API. Under normal circumstances, pushing the back button goes back one step, to the previous page. If you use history.pushState(), you start adding extra sub-steps to the current page. The way it works is, if you were to use history.pushState() three times, then start pushing the back button, the first three times it would navigate back in these sub-steps, and then the fourth time it would go back to the previous page.
If you combine this behaviour with an event listener on the popstate event, you can essentially set up an infinite loop of sub-states. So, you load the page, push a sub-state, then hit the back button, which pops a sub-state and also pushes another one, so if you push the back button again it will never run out of sub-states to push. If you feel that it's necessary to disable the back button, this will get you there.
On any browser, try a page Refresh/Reload after this, and you'll get stuck on a "Page not found" error, as it tries to find a page named no-back-button . (The browser is also likely to show no-back-button in the address bar too, which seems ugly.) To be fair, this is not the only solution here which suffers from this. The 3rd argument to history.pushState() is a url, and must be the url of your current page: use location.href instead.
This worked for me. Just change 'no-back-button' to "window.top.location.pathname + window.top.location.search" and it will stay the name of the page you are on, even in refresh
Я делаю онлайн-приложение викторины в php. Я хочу запретить пользователю возвращаться на экзамен. Я пробовал следующий скрипт, но он останавливает мой таймер. Что я должен делать?
Я включил исходный код. Таймер хранится в cdtimer.js
На этой странице перечислено несколько способов, которыми вы могли попытаться отключить кнопку возврата, но ни один из них не гарантирован:
В современном браузере это работает:
Это способ, которым я мог это сделать. Причудливое изменение window.location не сработало в chrome и safari. Бывает, что location.hash не создает запись в истории для chrome и safari. Так что вам придется использовать pushstate. Это работает для меня во всех браузерах.
Вы можете просто поставить небольшой скрипт и затем проверить. Это не позволит вам посетить предыдущую страницу. Это сделано в JavaScript.
Функция window.onunload срабатывает при попытке перейти на предыдущую или предыдущую страницу через браузер.
Надеюсь это поможет.
Я полагаю, что идеальное, но в то же время довольно простое решение, которое я использовал уже много лет.
Это в основном назначение окна «onbeforeunload» вместе с текущими событиями «mouseenter» / «mouseleave» документа, поэтому предупреждение срабатывает только тогда, когда щелчки находятся за пределами области действия документа (которая затем может быть либо кнопкой «назад», либо «вперед» браузера)
Я создаю одну HTML-страницу (index.html). Я также создаю один (mechan.js) внутри (скрипт) папку / каталог. Затем я размещаю весь свой контент внутри (index.html), используя теги form, table, span и div по мере необходимости. Теперь вот трюк, который заставит назад / вперед ничего не делать!
Во-первых, тот факт, что у вас есть только одна страница! Во-вторых, использование JavaScript с тегами span / div для скрытия и отображения контента на той же странице при необходимости с помощью обычных ссылок!
Это выглядит волосатым, но обратите внимание на имена функций и вызовы, встроенный HTML и вызовы id тега span. Это должно было показать, как вы можете вставить другой HTML в один тег span на одной странице! Как Back / Forward может повлиять на этот дизайн? Это невозможно, потому что вы прячете объекты и заменяете других на одной странице!
Как скрыть и отобразить? Здесь идет: Внутри функций в 'mechan.js' по мере необходимости, используйте:
Внутри index.html вызывайте функции через ссылки:
Надеюсь, у меня не болит голова. Извините, если я сделал :-)
Обычно плохая идея переопределять поведение веб-браузера по умолчанию. Сценарий на стороне клиента не имеет достаточных прав для этого по соображениям безопасности.
Есть несколько похожих вопросов,
Вы не можете отключить кнопку возврата браузера. Однако вы можете творить чудеса, используя свою логику, чтобы пользователь не смог вернуться назад, что создаст впечатление, будто оно отключено. Вот как, посмотрите следующий фрагмент.
Это в чистом JavaScript, поэтому он будет работать в большинстве браузеров. Также будет отключен ключ backspace , но ключ будет нормально работать внутри полей input и textarea .
Рекомендуемая настройка:
Поместите этот фрагмент в отдельный скрипт и включите его на страницу, где вы хотите, чтобы это поведение. В текущей настройке он выполнит событие onload DOM, которое является идеальной точкой входа для этого кода.
Протестировано и проверено в следующих браузерах,
В моем случае это был заказ на покупку. Поэтому я отключил кнопку. Когда пользователь нажал назад, кнопка все еще была отключена. Когда они щелкнули назад еще раз, а затем нажали кнопку страницы, чтобы перейти вперед. Я знал, что их заказ был отправлен и пропущен на другую страницу.
Хочу поставить "легкую" защиту кода на сайт.
Запрет правой кнопки сделал уже для защиты кода.
Как запретить на сайте нажатие CTRL+SHIFT+I и F12?
UPD: Нашел под по запрету F12.
Осталось найти сочетание клавиш)
Оценить 1 комментарий
Вот запрет на
CTRL+SHIFT+I
F12
CTRL+SHIFT+J
CTRL+U
Задайтесь вопросом. Кому нужен код? Простому пользователю он ни к чему, он даже не знает, что это такое. А тот кому он нужен, тот в любом случае найдет как его взять.
Вместо того чтоб страдать подобной <тут должно быть нецензурное слово>лучше сначала напишите что-то реально полезное, а так только сами себе грабли стелите
Тот же авито сажает вирус в расширения хрома при открытии инструментов разработчика, наверно как и Вы боятся спалить свой говнокод (а у них там действительно беда)
А еще подумайте вот о чем: что если инструменты разработчика уже открыты к моменту загрузки Вашей страницы? А что если я сижу на маке, где эти сочетания другие (CMD+I)? А что Вы будете делать с расширением которое позволяет блокировать обработку события контекстного меню скриптами в любое время? (У меня такое стоит)
Ну и напоследок: когда в Вашем коде появится реально что-то полезное, у Вас будут мысли не "каким еще костылем защитить мой код", а "как бы это написать так, чтоб потом выложить в опенсорс не стыдно было, да еще звездочек за это на гитхабе нахватать"тут>
Как ты говоришь: "Вместо того чтоб страдать подобной <тут должно быть нецензурное слово>лучше сначала напишите что-то реально полезное.". Сначала подумай хорошенько, где можно это использовать. Представь сто ты писатель, который выложил книгу на какой нибудь ресурс для чтения. Тебе будет приятно если ее просто скопируют и разнесут по всевозможным сайтам? Вот для этого и делают запрет на комбинации клавиш. Ведь можно запретить копирование, вызов кода или сохранения страницы.тут>
HubCat, если я автор книги, и выложил ее куда то в инет - моя цель явно, чтоб ее прочитали как можно больше народу. И то что ее скопируют другие сайты, будет только плюсом
Читайте также: