общая идея - перед закрытием окна браузера дождаться завершения работы внешнего приложения  (плагин, в моем случае VLC), 
которое оповещает нас o своем состоянии CallBack`ами.

для упрощения примера, CallBack будет дергать таймер :

если это дебажить, то мы увидим, что callBack finishWork() вызван пока мы в цикле сидим, но значение статуса остается прежним, пока не завершица процедура. 
цикл будет вечным.

ничего нового в этом нет, такая проблема например в Delphi решается через Application.ProcessMessages() или в VB Application.DoEvents для синхронизации параллельных вызовов,
однако в JavaScript этого нет.

собственно, как быть?  

Это сообщение отредактировал(а) CompWorm - 30.8.2013, 21:17

Не совсем понял, суть в том, чтобы закрытие окна не просто отменилось, а все равно произошло, но чуть позже?

да. 

в моем случае, перед закрытием окна я говорю VLC плееру "останови видео" и жду в цикле пока он остановить видео. 
об окончании процесса остановки он сообщает через callback.
вот крутясь в цикле я должен узнать как-то что callback сработал...

Добавлено @ 21:07
проблема в общем смысле в том, что в Javascript есть только один поток, и если в процессе выполнения процедуры произошел параллельный вызов другой процедуры, то первая об этом не знает.


Это сообщение отредактировал(а) CompWorm - 30.8.2013, 21:08

Судя по возможностях, что дарованы разработчику, все должно быть как-то так:  


В goSleep(delay) проблема в том, что:
а) поток будет так занят, что окно/вкладка с этим скриптом просто зависнет
б) браузер остановит это дело и принудительно выйдет изо все функций, вкладка благополучно закроется
в) браузер просто убьет выполнение скрипта из-за излишней нагрузки


Можно было бы поиграться с window.close(), но в большинстве браузеров уже пофиксили самые изощренные попытки закрыть окно, открытое со ссылки, а не со скрипта. Хром даже не выводит окошка с вопросом.

Закрывание окон — вообще больная тема последним временем... 

А чем нежелательно закрытие окна до остановки видео? Может это можно решить на другом уровне...

я в курсе. две точки синхронизации вызовов на единственном потоке - это до входа в window.onbeforeunload и после, при том промежуточные вызовы типа goSleep ни на что не влияют, фактически браузер зависает на время выполнения каждого вызова. в этом и состоит проблема.

ОФТОП:

исходная суть задачи - по таймеру, асинхронно, менять видео в нескольких VLC на одной закладке браузера. 
опробовано два подхода:
1) рассувать плееры, каждый в свой iframe, по таймеру динамически переоткрывать iframe с новым плеером, с новым адресом потока.
это вызывает падение VLC по рейс-кондишан, как я считаю, то есть во время долгой буферизации в нескольких плеерах по таймеру может поспеть переоткрытие ifram'а.
в такой форме мне этот код торжественно вручили на доработку))) 
собственно, я выяснил, что без видео эти ifram'ы с vlc закрываются без падений, и идея починки была в том, чтобы отправить плееру стоп перед закрытием его iframa, дожидаться события кол-бэка, что он стопнут и закрыть окно. 
это я выше и описал.

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

я не знаю, честно говоря, как управляется память в javascript, но не исключаю и другой рейс-кондишан - окно ifram'a или браузера закрылось, а плеер всё ещё в памяти сидит и закрывается, пока его гарбидж коллектор не прибьёт, внезапно обнаружив, что сылок на dll ки от vlc больше нет... произойти это может не скоро, так как другие плееры всё ещё показывают видео, стало быть либы всё ещё используются, тогда происходит не падение, а утечка памяти. утечку памяти при остановки плееров я часто наблюдаю в FireFox. 
ещё раз, это моя догадка, поправьте, если кто точно знает как управляется память при использовании плагинов.

то есть оба варианта требуют ловить события перед закрытием окна.

Добавлено через 5 минут и 29 секунд

это не серьёзно. приложение должно завершаться самостоятельно, не оповещая пользователя о своих проблемах в коде.  

а! был третий вариант!
3) хранить в главном окне хэндлиры на все VLC'ы, посылать каждому стоп и ждать колбэка в основном окне. 
по получении отклика - переключаться на следующий поток (или переоткрыть iframe). 
идея очень многообещающая, но с треском провалилась, ибо я не осилил поиск объекта внутри ifram'а, пишет что access denied. судя по гуглу, что-то надо крутить в настройках http у сервера.  но это уже совсем отдельная тема.  

Не совсем верное утрверждение.
WebWorker пробовал?

akizelokro, о, не знал, спасибо за попытку - плюс в репу!
но у меня к сожалению, требование заказчика - IE9, а поддерживается web Worker начиная с IE10   
кроме того, я не уверен, что получу событие от WebWorker не выходя из window.onbeforeunload ...

есть еще какие-нибудь идеи?

Это сообщение отредактировал(а) CompWorm - 4.9.2013, 18:54

За "репу" спасибо!
Ситуация у тебя здесь аховая. Закрытие страниицы производить только основываясь на том, что плагин доработает (остановится как честный человек, - полагаться можно, но не нужно). Плагин можт крякнуться и из-за другого окна и по другим причинам. В этом случае отзыва ты от него не дождёшься никогда. Имхо, нужен определенный таймаут, для того, чтобы он отозвался. Если он не отозвался за достаточное время, то считать его выбывшим из строя.

Проблемe со всякими таймаутами, которые в JavaScript реализуются со своими особенностями, я решаю просто. Пишу php-скрипт, который делает задержку на несколько секунд, делаю ajax вызов этого скрипта и даже потом ответ не читаю, и проверяю то, что мне надо. Решение криво своеобразное, согласен. Но с JavaScript иных не вижу.




Это сообщение отредактировал(а) akizelokro - 5.9.2013, 05:48

к сожалению у нас dojo вместо jquery... внезапно.  
ладно, в целом можно считать проблему решенной, вектор движения обозначен, дальше сам пойду изобретать.
Всем спасибо за участие. 

Ну, и поправлюсь. Не "решаю просто", а когда решить их иначе нельзя. 
   Есть, к примеру, заказчик, и хочет невозможного. Как потом оказывается. Потому что ТЗ делаются на несколько дней работы чаще всего, все детали порой не прорабатываются.. Я не заполоняю этими sleep.php свою работу. Но приходит момент и, по-другому, получается, что и нельзя. Убейся, но сделай. Тогда и приходится.

наш случай )))