M 12345c

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

12345c, очень интересная вещь...

Выполнял прямо в адресе на странице с Вашим кодом, void() по идее гарантировал отсутствие перехода.

Результаты:
FF1.5, Op. 9.01: true, true, true, true, true, true
IE 6.0.2900 (SP2): false, false, true, true, false, false
Op. 8.02: true, true, true, false, false, false (!)

Первая строчка (они же самые новые), видимо, действуют правильно.
Про IE6 давно была известна такая беда, что self у него находится в сложных отношениях с window, а попросту глючит. Получается, window в нем вообще стоит особняком от всех своих алиасов. 
Но вот результат 8-й оперы я объяснять не берусь...

Это сообщение отредактировал(а) 12345c - 31.10.2006, 15:45

SelenIT, 

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

window - объект, self - в IE св-во (или атрибут) объекта window, результат закономерен, то же и со следующим сравнением (window===top).

откройте во фрейме - получите другой результат, и опять все будет ясно.

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

AKS,


С одной стороны, оно так... но с другой стороны - свойство это содержит ссылку на сам объект, а т.к. в JS все объекты, кроме примитивных типов, являются ссылками (поправьте, если я в этом заблуждаюсь) - то это должна быть в точности та же самая ссылка, и в новых браузерах (FF, Op.9) это так и есть. Опять встает вопрос "кто же прав и почему".


В данной теме все же интересует поведение верхнего окна. Опять же, следуя логике предыдущего пункта, top и self - принципиально разные свойства объекта window, почему же для верхнего окна они содержат одну и ту же ссылку (top===self)? А раз так, то что мешает каждому из них содержать честную ссылку на сам объект? Нет, что ни говорите, логика здесь какая-то странная.

И наконец: какой логикой Вы объясните поведение 8-й Оперы, где глобальный контекст (this) не эквивалентен ни window, ни его свойствам-псевдонимам?

SelenIT, 

А какая-бы она ни была, все-таки ведь какая-то логика есть (она не может не есть ;) ). И ее нужно понять. Давайте опять с первого сравниения в IE:

Можно такое понять? А почему бы и нет! Можно предположить, что в IE есть явный глобальный объект window и есть еще window.window - св-во, указывающее на текущее окно браузера, и это не сосем одно и то же при строгом сравнении. А можно предположить, что это всего-навсего различия в работе оператора строго сравнения. Т.е., в FF при строгом сравнении один результат, а в IE - другой, и это как раз благодаря оператору строгого сравнения, которому удается "углядеть" какую-то разницу в IE.

Разными они будут во фрейме, а в одиночном окне указывают на текущее окно. Отсюда и результат, который одинаков во всех браузерах:


Объяснять я ничего не хотел бы, я ведь предложил дружно, так сказать, попытаться отыскать эту самую логику. 
Почему в Opera'х сначала было this===window, а теперь нет - видимо пошли по пути разработчиков IE...

AKS, по поводу IE в той теме трехлетней давности на Xpoint'е было предложено объяснение, которое кажется мне очень правдоподобным. Если так, то какой бы ни была исходная идея, реализована она все-таки глючно).


Извините, Вы, видимо, перепутали - это теперь все четыре ссылки (window, top, self и this) эквивалентны (как в FF), а в 8-й версии было что-то странное - ссылки на окно были эквивалентны между собой, но не совпадали с глобальным контекстом.

Это сообщение отредактировал(а) SelenIT - 28.10.2006, 15:34

SelenIT, 

А мне, вообще-то, нравится философия тех, кто обожает FF и не устает "бросать камни в огород" IE. Любое отличие от FF - "глюк"!
PS На Xpoint я никакого объяснения не видел, если Вы, конечно, не считаете объяснением вот эту фразу: "Похоже, хороший косячок нарыли"...

Добавлено @ 15:49 
SelenIT, по большому счету, вот что есть в стандарте, касательно всех top&self&window.window:

AKS, объяснением я посчитал это:
Глюком, соответственно - вторую часть этой фразы. И отличия от FF тут ни при чем. Вообще, хоть я и вправду обожаю FF и не собираюсь переходить с нее на 9-ю оперу (которая объективно как минимум не хуже), многое в "лисьих штучках" меня тоже порядком достает - например, то как она рендерит "настоящий" XHTML (только после полной загрузки кода, и в этот же момент происходит onload, а картинки как ни в чем ни бывало грузятся себе потом). Вообще, глюками всегда кажется непривычное поведение и отличия от злополучных "интуитивных представлений" о том, "как это должно быть". Побочный эффект этого - для человека, привыкшего к глюкам, глюком кажется "правильное" (с точки зрения стандартов) поведение. Впрочем, стандарты тоже пишут люди, так что субъективный фактор и тут не исключается... но это уже далеко уходящая в оффтоп общая философия:)

12345c, а нельзя ли выделить обсуждение св-в объекта window в отдельную тему? А то SelenIT напугал меня фразой:

, а я хотел бы еще "попереливать из пустого в порожнее" на эту тему. 
Или, может быть, можно прямо здесь?
Кстати, у меня одинаково работает конструкция 
с аргументами top.s и с s...

Zeroglif, 

А я с некоторых пор (благодаря Вам) смотрю на это под таким углом зрения - IE6 сделан очень давно и в наши дни многое может казаться "глючным", но на самом деле не все так просто. 
Почитывая разные книжечки о программировании, я где-то встречал следующую концепцию:
"Аналогично, но не идентично". 
Может и здесь что-то подобное?

Вообще-то в контексте моих сообщений это должно было выглядеть как-раз наоборот...

У меня появились еще кое-какие соображения насчет "глюков" IE, хочется поделиться ими с собеседниками.
Начну с "равенства, но не тождественности двух объектов" (window & self). Может быть  все же это не "промах", а как раз "злой умысел" разработчиков с целью лишить нас возможности писать в дочернем окне что-нибудь, типа:

? Ведь в таком случае понятно, почему window !=== top, так ведь? Может, конечно, возникнуть вопрос: "Почему я не могу писать top.onresize = function() {}?". Но, думаю, у разработчиков возник бы резонный встречный вопрос: "А почему бы не написать именно в окне верхнего уровня onresize = function() {}?"
Продолжу уже примерами с Xpoint (куда SelenIT настойчиво предлагал обратиться за знаниями). Вот один "вариант глюка":

Оба предупреждения выдадут true, и это может кого-то удивить (и, в общем-то, удивило). Однако, удивление быстро пройдет, стоит только прочесть на MSDN Library следующую ремарку:

Т.е., хоть body и может "по-хозяйски" распорядиться методами "хозяина", отнюдь "тело" не будет caller'ом для перечисленных методов (и onload в частности).
А вот самое интересное (тоже с Xpoint):

Можно связать это с предыдущим примером, предположив, что раз body "подменил на время" window, и хоть this==window, но не совсем window (this!==window). Но вот стоит только сохранить указатель на вызывающий объект в глобальной переменной:

, или передать параметром в функцию:

 - результат будет противоположным. И вот здесь уже я объяснения пока не нахожу. Из примера, конечно же, видно, что дело в контексте выполнения, но еще не совсем все ясно. 
Конечно же, можно все это списать на "врожденную невнимательность и беспечное отношение к работе" со стороны разработчиков IE. И это было бы легче всего...

Вот над этим:
 
долго думать не стал. "Потыкавшись" немного, решил, что объяснение - вот оно:

Ну и как вам, собеседники? Оказывается, окрыв страницу, IE создает window, но это "окно" не идентично тому, что будет после полной загрузки страницы.

AKS, а по-моему, объяснение в этом:

Функция-то не знает о глобальном объекте window - она тупо ищет переменную по scope chain и в итоге находит свойство глобального объекта с таким именем...

SelenIT, 
А если так, то "кто там и что знает":

 - без Zeroglif не разберешься...

AKS, признаю, поторопился. Новые факты явно в пользу Вашей версии. Подождем Zeroglifа...

SelenIT, 
продолжая пытать "преступника" IE, удалось выяснить следующее:
1 обращаясь к ключевому слову window в коде программы, мы получаем доступ к глобальному объекту;
2 обращась к ключевому слову window из документа (в аттрибутах тэгов, например), вместо глобального объекта мы получаем кое-что другое, а именно window.window, window.self, и т.д.
Истину получим вот так:

Здесь ключевое слово this и есть глобальный объект, чье событие было "обработано", а window сами видите что такое (именно то, что разработчики "обозвали"  Attributes/Properties).  
Ну и как Вам "глюки"? Согласитесь, для "глюков" все слишком закономерно...
 
 

AKS, закономерно-то оно закономерно... но в чем же тайное предназначение этой закономерности?

Разве нормально (с точки зрения JS-разработчика), что идают настолько разный результат? Какими практическими соображениями оправдано отсутствие второй ф-ции во втором алерте первого примера? Почему-то эта логика от меня упорно ускользает...

ребят, я наверное новичок, но сравнение указателей на объекты дело очень противоречивое. идентичность объектов сравнивется по наличию свойств, например. ==, === - не критерий.

указатели на объекты по-разному устроены в различных браузерах. поэтому и получаются разные значения при сравнении.

SelenIT, 

 Вы мой, теперь уже предпоследний пост не прочитали (а жаль - я так старался целый день, гнул свои выпрямленные расческой извилины ;) ). 
Вот если бы прочитали, то было бы понятно, что нет функции, так как ее Вы не определяли! Вы писали:

? Нет! Попробуйте так:


Добавлено @ 16:36 
JSman, 

А мы, между прочим, давным-давно только про IE беседуем. Присоединяйтесь!

Это сообщение отредактировал(а) AKS - 30.10.2006, 16:43

AKS, что обработчики событий глобального window и его одноименного свойства (с вариациями в виде self и т.п.) абсолютно "отвязаны" друг от друга - понятно, спасибо (об это набивали шишки еще 3 года назад). Теперь же меня интересует не академическая, а практическая сторона: не "почему так", а "зачем сделано именно так" (если, конечно, так сделано специально)? Моя интуиция все же упорно требует, чтобы все свойства (включая обработчики событий) объекта окна были доступны по любой ссылке на него - и мозилла с оперой этих моих ожиданий почему-то не обламывают. Хочется постичь логику IE не только в симптомах, но в сути...

SelenIT, 

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

Надеюсь, теперь кто-нибудь еще что-нибудь расскажет...

А Вы не читали вот здесь ту часть топика, что касается объекта Event в IE? 
После этого я как-то иначе стал воспринимать этот сложный браузер (хотя и до этого знал, что он не так-то прост и "неуклюж", как принято теперь считать)... Почитайте, если не читали.

А может и не специально. Я вроде бы несколько раз предположил, что может разработчики IE как раз такие "недотепы", что допустили такое в своем браузере. Мало ли, может кто-то запил в момент сдачи проекта ;) - а мы теперь с Вами ломаем голову...  ;)

AKS, спасибо, обязательно постараюсь "асилить". Ту тему я смотрел, но бегло - теперь понимаю, что надо было перечитывать ее несколько раз до просветления. Объектная модель событий - до сих пор вообще мое слабое место в JS, а уж тонкие нюансы ее реализаций...

...И все же насчет возможной защитной ф-ции разделения обработчиков window и window.window осмелюсь выразить сомнения - маловероятно, что разработчики предусмотрели это, но пропустили "мегафичу" в виде "opener=1; close();"...

В IE глобальный объект (global) и окно (window) - разные сущности, объединённые в некий global namespace. IE на себе тащит не один скриптовый язык, видимо нужно, чтобы разным языкам комфортно работалось совместно в окне браузера. Может ещё какие причины для разделения были, не знаю, предполагаю только. Но если строго следовать логике EcmaScript, то разница никого не должна волновать, все алгоритмы EcmaScript должны работать так, будто объект один и тот же, как бы его не трогали. Но IE в этом контексте не смог решить некоторые проблемы вроде нумерации свойств глобального объекта плюс есть узкие места, где эта разница начинает влиять, к примеру, те самые "скрипты в атрибутах" или ID элементов, равные свойствам window.

Проблема этого примера

связана со скриптом в аттрибуте, это intrinsic event. Scope chain такого обработчика са-мо-дель-ная во многих браузерах, и везде по-своему. К примеру, там может быть объект document, для элементов форм там может быть и будет сам элемент и т.д., а самое главное не гарантировано то, что на конце цепочки будет глобальное свойство window, а не "текущее window". Как-то ведь надо было для фреймов реализовывать идею ТЕКУЩЕГО ОКНА (window.self или его синоним window.window). Значит, в одиночном окне при встрече IE с intrinsic event, он создаёт scope chain, специально отделяя текущее окно (из html которого с ним пытаются работать) от глобального, то есть идентификатор window - это сокращённая форма window.window. Другой вопрос, что тождественность всё-таки надо было реализовать правильно, в одиночном окне ссылки должны бы вести в одно место...

Зачеркнул. Не о том это я, намешал всё  в кучу, тут всё-таки особенность именно в body. Буим думать дальше.

Это сообщение отредактировал(а) Zeroglif - 30.10.2006, 20:04

Zeroglif, 

Так ведь они ведут в "одно место", разве нет? А где вообще на этой почве возникают какие-либо конфликтные ситуации? Или проблема только в том, что некто Вася Пупкин не смог реализовать какой-нибудь такой вот "перл":

 ?
SelenIT, 

А я не ошибаюсь, что понравившаяся Вам Opera 9 позволяет закрыть окно вообще без opener'а? Если не ошибся, то чего же ждать от "старика"?

Добавлено @ 19:12 
Честно говоря, пусть это все "глюки", но я рад, что все-таки сегодня раскопал закономерность...

Эх! Забыл поблагодарить собеседников, которые помогли мне понять window.window в IE! Однако сказывается отсутствие должного воспитания! А благодарить ведь есть за что - мне эта alert(this===window/* false */) да-а-авно покоя не давала, и здесь вдруг раз - все "прояснилось"... ;)
Так что спасибо, SelenIT, Zeroglif! 

AKS, спасибо и Вам, также присоединяюсь к благодарностям Zeroglifу, и отдельное спасибо автору темы, уважаемому 12345c!

И я благодарю автора темы - спасибо еще и за то, что не "зарезали" оффтоп!

Эх, какой здесь простор для бесконтрольной мозговой деятельности, время от времени возникающей в моей голове! ;)

 SelenIT, Zeroglif! Снова обращаюсь к вам! Мне бы очень хотелось вот здесь написать маленькую, о-о-очень маленькую заметку на эту текущую тему (буквально два-три абзаца). Так вот посоветуйте - как представить все это (я имею ввиду window!==window.window). Как недоработку или же как особенность браузера? 
Сами понимаете - хотелось бы "похвастаться", написав, что мы тут с вами узнали где и в какое "окно"  мы "лезем" ;). Хотя если хоть один из вас не проявит интерес вот к этому сообщению, то я буду считать, что этой темой не стоит "хвастаться". Опять же буду расценивать это, как помощь с вашей стороны.

Лично я для себя точно ничего не выяснил, мне не открылось:

a) почему такой своеобразный this в body.onload и связано ли это с тем, что он хостит чужой обработчик?
б) почему криво реализована тождественность и есть ли смысл в такой кривости;

По пункту а) остаётся только гадать. По пункту б) я чирканул письмецо одному из разрабов JScript (E.Lippert), но он так давно этим не занимается, что может легко забыть ответить. 

Zeroglif, 

Да, я тоже вот сейчас "отдышался", пришел в "себя", и понял - рано пока "шорох" подымать...

Ого, вселяет надежду...

Ну-у-у, значит не судьба! Будь что будет, от добра добра не ищут...

А что, вроде бы написано же у них, что хостит?
Я пока про intrinsic events хорошенько почитаю (раньше-то не читал!). Получается так, что каждая функция в аттрибуте создается вариантом, с использованием конструктора Function? Может это накладывает какой отпечаток?

Я бы сказал, что это ошибка проектирования в бОльшей мере.
Или попытка как-то закрыть дырку с отсутствием глобального объекта до окончания загрузки. Об этом говорит такой эксплойт: 


http://secunia.com/advisories/15546/

WingedFox, 

Вот, пожалуйста! Еще один вариант объяснения поведения IE. А ведь действительно, может же быть такое поведение результатом "наложения заплаток" на движок. 
А как раньше было с этими "окнами" в IE? 
"Раньше" - это я имею ввиду IE4, например. Я его даже издалека не видел... 

Это сообщение отредактировал(а) AKS - 31.10.2006, 13:05

Кстати, только что случайно наткнулся на занятный драфт от W3C - оказывается, полгода назад там все-таки задумались о том, чтобы навести некий порядок в "оконной" проблеме. Там, в частности, требуется (must) тождественность (именно в смысле эквивалентности) значений атрибутов window и self друг другу и самому объекту window. Похоже, браузеры 2006 года решили этому последовать, и имхо это хорошо.

Интересно, как по этой части обстоят дела в IE7...

SelenIT, это же попытка реализовать все то, что ваша "интуиция упорно требует" !   ;) 
А если серьезно - почему "занятный"? Вроде как раз то, что нужно, так ведь?

Вообще, такие вот "черновики" долго превращаются в стандарты? 

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

В IE7 всё те же проблемы, проверил быстренько из адресной строки.

ой ну и поздновато я присоединился))
постараюсь наверстать упущенное. если вдруг повторения, прошу простить.

говоря о логике ие.



по поводу их значений.
по моему мнению ие совершенно правильно сравнил их.

== - сравнение их значений (values)
=== - проверка значений и совпадение типа (не встроенного типа object).

self, top - свойства window, а не сам хост. поэтому они не идиентичны.
this в тэге HEAD - ссылка на window. а если она внутри тэга body, то ссылка на элемент в котором this находится. исключением является <BODY ONLOAD="this. ...">, где this - это ссылка на window? потому что document.body.onload===window.onload

Добавлено @ 00:01 
мне кажется this в <BODY ONLOAD="this. ..."> - это как переменная, она хостом не является.
поэтому при проверке this===window буде false

JSman


Алгоритмы сравнений и в том, и в другом случае схожи для object type. Мы же исходим из того, что и window, и top, и self имеют один и тот же тип - object. Значением этих идентификаторов является ссылка на объект. Если объект у них разный, то мы должны были бы получить false уже при нестрогом равенстве, чего не происходит.

Равенство (11.9.3 The Abstract Equality Comparison Algorithm) 
The comparison x == y, wherex and y are values, produces true or false. Such a comparison is performed as follows:
1. If Type(x) is different from Type( y), go to step 14.
2.If Type(x) is Undefined, return true.
3.If Type(x) is Null, return true.
4.If Type(x) is not Number, go to step 11.
...
11.If Type( x) is String, then return true if x and y are exactly the same sequence of characters (same length and same characters in corresponding positions). Otherwise, return false.
12. If Type(x) is Boolean, return true if x and y are both true or both false. Otherwise, return false.
13.Return true if x and y refer to the same object or if they refer to objects joined to each other (see 13.1.2). Otherwise, return false.

Строгое равенство (11.9.6 The Strict Equality Comparison Algorithm) 
The comparison x === y, where x and y are values, produces true or false. Such a comparison is performed as follows:
1.If Type(x) is different from Type(y), return false.
...
13.Return true if x and y refer to the same object or if they refer to objects joined to each other (see 13.1.2). Otherwise, return false.


Это не должно иметь значение, объект может иметь свойство, значением которого будет ссылка на него самого. При сравнении имя-объекта===имя-свойства-объекта мы должны получить true, т.к. это один и тот же объект и алгоритм сравнения прописан чётко, host/не host не должно играть никакой роли вообще.

я поясню свою логику, думаю,  что сравнение объекта хоста с его переменными self, top не должно быть true, так как теряется смысл использования строгого равенства.
 тогда зачем нам ===? если есть возможность использовать ((x==y)&&(typeof(x)==typeof(y))).

более того, объект хост существует только в единственном экземпляре, все остальные, переменные, -ссылки на него. поэтому и тип разный, хотя и пишет, что object. а вообще по документации существует 4 типа объектов..

Фишка в том, что концептуально EcmaScript-y наплевать с высокой колокольни на причуды хоста и иже с ним. Алгоритмы должны быть реализованы так, как описаны, если UA считает, что реализовал EcmaScript комформно.


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


В IE global namespace - это чёрный ящик, объект Global сам по себе, WINDOW само по себе (но нам незаметна разница), а кроме того встречаются какие-то объектные привидения для работы с ID элементов, можно даже попробовать как-нибудь это доказать...

Zeroglif, 
 
Ух, обожаю "привидения"! Еще одна тайна! Только за это можно в IE влюбиться навеки...
А если серьезно, то может, хотя бы в общих чертах, но чуть подробней, чиркнете об этом пару строк?

мне кажется Microsoft просто дальше пошли. и дело не в неправильной реализации, а то, что EcmaScript больше полагается на Web, а Microsoft использует JS для многих целей (типа WSH)


typeof, если не изменяет память с javascript 1.0, а === с 1.3
более того, посмотрел в одном справочнике, что 
=== - NN n/a  IE J3  ECMA n/a IE 3  ECMA n/a.

т.е. ИЕ раньше начал использовать ===, чем это стало стандартом

Это сообщение отредактировал(а) JSman - 2.11.2006, 21:00