Проверить наличие меню/панели инструментов/адресной строки/статуса

[Ruark]

Методом window.open открывается новое окно, в котором убрано меню, панель инструментов, адресная строка, строка статуса. Здесь все понятно.
Теперь стоит задача несколько обратная. Каким образом джаваскриптом можно проверить, в существующем окне браузера присутствует ли меню, панель инструментов, строка статуса?

[Gvozd]

померять размеры самого окна и рабочей области, и сравнить разницу с заранее сделанными замерами на тестовых браузерах.
короче говоря сильно ненадежно,муторно, и некросбразуерно.
других вариантов кросбразуерных, скорее всего нету.может быть гугл знает, но это вы сами у него спросите.
Можно еще открывать тестовое окно БЕЗ всех дополнительных менюшек, и сравнить разницу с основным окном.
НО!в любом случае вы не узнаете что именно имеется/отсутсвует из меню и прочего.
PS а собственно для чего бы могло это понадобится?не поделитесь в связи с чем такая нестандартная, и ан первый взгляд бессмысленная задача?
Собственн

[Ruark]

Отчего же не поделиться?
Свой закрытый корпоративный сайт. Система для ввода данных и поиска информации. База данных на Оракле. Активно используется AJAX. Но в силу тупости отдельного ряда юзеров как-то надоедает удалять последствия нажатия F5, BackSpace(назад по хистори) и прочее.
Платформа однозначно только ИЕ, тут все решено однозначно. И очень хочется отключить и меню, и навигацию, и адрес. Путем открытия нового окна я это делаю. Но. Есть ряд юзеров, которых хочется убить. Которые могут скопировать ссылку и потом вставить в отдельном окне и работать со всеми панелями.
Я видел решение данного вопроса так - при загрузке страницы я анализирую, есть ли в браузере меню, панель навигации, адресная строка, строка состояния. Если нет - значит это "нужное мне" окно с отключенными фишками и все в норме. Если же что-то из этого есть - на страницу выводится только одна ссылка на открытие окна с "нужными мне" параметрами.
Может, уважаемые знатоки подскажут другой способ, как указанный мной алгоритм можно реализовать?
Платформа однозначно только ИЕ, никакой кроссбраузерности.

[Kolyaj]

Извиняюсь, конечно, что не в тему, но разработчик, заставляющий пользователей подстраиваться под него -- хреновый разработчик. Не надо бороться со следствием, надо бороться с причиной. Почему пользователи открывают приложение в новом окне? Может им так удобней? А если им так удобней, то так повышается производительность их труда, а значит вы, мешая им работать удобно, вредите своей компании. И очень плохо, что этого никто не понимает.

А проблема-то элементарная. Поставьте обработчик события unload и спрашивайте пользователя, действительно ли он хочет закрыть приложение.

[Ruark]

Уважаемый, может быть, я неправильно выразился или неправильно обрисовал задачу. Но Вы в корень неправы.
1. Пользователи не открывают в новом окне приложение. Это я открываю приложение в новом окне. Потому что убрать панели можно только при открытии нового окна методом window.open задав соответствующие параметры.
2. Мне нужно, чтобы скрипты работали при отсутствии панелей, чтобы юзер НЕ МОГ сделать history.back или F5. Почему? Потому что запись идет в оракловскую базу, с ручным управлением транзакциями. Причем ряд операций выполняется аяксом.
3. Кто будет отвечать, ежели юзер нажмет хистори.бак а потом хистори.форвард и в результате транзакция или не отправится или что-то сработает не так? Правильно, разработчик. И вот будет он хреновым именно в том случае, ежели у юзера будет таковая возможность. Потому, уважаемый, давайте не будем судить о качествах разработчика;-)
Сейчас я понятнее выразимл свою цель?

[Gvozd]

вашу задачу, по недоступности такого рода манипуляций с базой(не с браузером) можно решить по другому.
к тому же даже без панелей, всегда есть клавиутура.
Как бы я решил вашу задачу.
сделал бы переменную в JS(не в кукисах, а именно обыкновенную переменную), в которой бы хранился временный уникальный идентифиактор.
это будет ID операции.
прив выполнении любой операции, перелельно посылается этот ID, а в ответе возвращается новый ID, помимо остальной инфы
то есть ID может быть получен при загрузке страницы(прямо в коде HTML-а его инициировать), либо, как часть AJAX-ответа.
соответсвенно уже сработавший ID в дальнейшем не использутся, и отрабатывает с ошибкой, не давая сделать операцию записи в базу.
При переходе назад, если выполняется какая-то операция, то она попытается выполнится со старым ID
аналогично при рефреше.
добавляем отслеживание HTTP-Referer, и вуаля: никакие путешествия при помощи стандартной навигации не пошлют лишних действий.
в общем-то это общая схема, поверх которой еще надо пару проверок сделать, и протестировать.
но это достаточно дружелюбный вариант, и самое главное более правильный и защищенный, ИМХО

[Kolyaj]

Ruark,
свою некомпетентность вы уже доказали. Для общего развития: на предыдущую страницу можно перейти еще через контекстное меню и с помощью ALT+Left. А отвечать будет разработчик, потому что это он спроектировал приложение так, что нажатие history.back приводит к ошибке.

[Ruark]

Коля, Не буду Вам доказывать, уважаемый, свою компетентность - смысл?
1. Контекстное меню и комбинации клавиш я отключил первым же делом. Не счел нужным указывать это здесь, меня волновал другой вопрос, который я собственно и задал.
2. У Вас конечно высокая карма и Вы уважаемый человек, однако кроме Ваших суждений по поводу хреновости программистов и чьей-либо компетенции я ничего не прочитал. Вы хотели показать какой Вы умный? Браво. У Вас получилось. Я в восхищении.
3. Дискуссию с Вами по этому поводу я желал бы прекратить. Ибо в ней толку никакого.
Гвоздь - спасибо за решение, я обязательно возьму это на вооружение. Просто с браузером еще хотелось бы похимичить "для общего развития". Я новичок в джаваскрипте, и не стесняюсь это признавать.

[Gvozd]

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