to post messages and comments.

← Все записи с тегом IE

@OCTAGRAM:

15-10 лет назад…

Доминирует IE, с ним конкурирует… например, Maxthon, тоже на движке Trident.

В языке JavaScript трассирующая сборка мусора соседствует с полнейшим отсутствием поддержки слабых ссылок. Когда-нибудь эта пороховая бочка должна была бахнуть, и она бахнула. Разразился скандал про несобираемые цепочки из JavaScript и DOM элементов, во всяких jQuery появились разные костыли, заменяющие слабые ссылки. По результатам скандала в браузерах могли бы наконец появиться нормальные слабые ссылки, но не появились, зато производители бросили жирную кость поклонникам трассирующей сборки мусора, реализовав сборку циклов в FireFox и Internet Explorer. С тех пор о быстрых браузерах остались только воспоминания.

Будущий лидер веба известен в узких кругах красноглазиков. Браузер называется Konquerror, а движок — KHTML, и у его разработчиков даже и в мыслях нет, что они вытеснят вообще всех, кто на слуху: IE, Оперу, FireFox.

@OCTAGRAM:

Некоторые факты об mshta.exe:
1. Помешать закрыть окно с не сохранёнными данными при помощи beforeunload не получится. Вопрос вылезет, но что ни отвечай, всё равно закроется. Это известный, признанный Microsoft баг.
2. setAttribute для динамически созданных элементов DOM вообще по боку. Только свойствами можно порулить поведением. Пришлось свои библиотечки адаптировать под эту инопланетную среду. Я всегда считал, что манипуляции с DOM первичны, а всякие свойства типа style — это нечто вроде синтаксического сахара. В mshta.exe всё наоборот.
3. Если checkbox вставляется в другой DOM элемент, его checked обнуляется.
4. Скрипт с type="text/javascript" не запустится
5. Свойства приложения описываются в теге HTA:APPLICATION, но никто не знает, какой URI у пространства имён HTA. Его просто нет, и он рвёт шаблоны зияющей пустотой своего отсутствия.
6. Пока не нашёл работающего способа сделать background-size: cover. Библиотеки, которые должны работать даже в IE7, не могут в mshta.exe
7. Динамически навесить обработчик события, записанный строкой, не получится. Подойдёт только настоящее замыкание.

Есть и положительная сторона. Я давно не видел, чтоб что–то браузерное так быстро работало. Electron такого ощущения не давал.

@OCTAGRAM:
IE

Разбирался, почему в очередном месте у всех работает, а в IE — нет. Похоже, всё же мой косяк, просто IE неласков, и не прощает ошибок. Писал в кукис значение, которое мне показалось необязательным экранировать, ведь в нём никогда не будет точки с запятой. Эх, если б я только знал. ЕСЛИ Б Я ТОЛЬКО ЗНАЛ, НАСКОЛЬКО ВАЖНО ЗАЭКРАНИРОВАТЬ ПРОБЕЛ. Потому что IE его уже не заэкранирует, а пошлёт обратно как принял, ну а на сервере от этого парсеры сломаются в куче мест в чужом коде. Блиииин, придётся вычищать теперь эту дрянь из всех клиентских кукисов, потому что пытаться сейчас починить это на сервере будет ещё сложнее.

@OCTAGRAM:

А кто это у нас такой уникум, который не–ASCII символы в HTTP шлёт? Конечно, Lumia. Хорошо, что на этот раз я лучше подготовлен технически, и мне не приходится в Squid rewrite_url править косяки, которые гарантированно вызовут 400 Bad request на некоторых веб–серверах типа Caucho Resin. Можно даже порадоваться тому, что логи стали чуть более читабельными.

@OCTAGRAM:

P3P в IE6
До более близкого знакомства P3P в IE мне казался местечковой фишкой вроде security="restricted" или CSP. Даже засел W3C спецификацию читать. Теперь я вижу, что нет. И в Windows 10 его совсем выпилили. Если вкратце, чтобы куки работали через домены, каждый раз, когда ставятся куки, надо ещё послать заголовок P3P с содержимым CP="This is not a privacy policy!" или аналогичной невалидной строкой. Это всё, что вам нужно знать про P3P.

@OCTAGRAM:

Непонятно, почему, но у некоторых клиентов с Internet Explorer всегда срабатывает window.top != window.self без всяких видимых причин. Пытался заменить какой–нибудь другой конструкцией, всё без толку. Понакупят блин Люмий, и чё с ними теперь делать. К несчастью для меня, после катастрофы у FirstVDS я ещё несколько месяцев не смогу разбрасываться людьми. Придётся что–то решать с теми, кто остался.
Ещё я выяснил, что в некоторых IE не работает нормально яндексовский (да и вообще, по Интернету если посмотреть, распространённый) код асинхронной подгрузки скрипта, когда находится самый первый тэг скрипта, и в его родителя перед ним добавляется новый скрипт. Это срабатывает только для первого скрипта, а потом либо управление теряется, либо следующие добавленные таким образом скрипты игнорируются, я так и не понял. Долго искал, может, синтаксическая ошибка. Чувство было, что браузер читает скрипты энным местом. Тут выполняю, а тут не хочу.
Всё обёрнуто в try-catch с уведомлением об очередном приколе, но не тут–то было. И скрипт не грузит, и о проблемах молчит. Мне жалуются, а я понять не могу, как такое может быть. Переделал везде, чтоб добавлялось в конец head. Вроде полегчало.
Причём, в моём IE увиденные в логах приколы не воспроизводятся, хотя я в логах вижу странное поведение даже у идентичных моему User-Agent, а не только на Люмиях.

@OCTAGRAM:

На долю IE сейчас приходится 3,1% просмотров. Были времена, когда не верилось, что доживём до этого.

@OCTAGRAM:

superevr.com
A flaw in Internet Explorer could expose users to JavaScript exploits and Universal XSS by abusing the way the browser classifies websites into specific security zones.

@OCTAGRAM:

Всё не так уж плохо. На моём сайте (не скажу, каком), по статистике за последнюю неделю:
Opera — 162 визита
Firefox 3 — 159 визитов
MSIE — 110 визитов (из них 57/20/33 соответственно 8.0/7.0/6.0)
остальное — всякие Safari, Opera Mini, Iceweasel и Chrome
В процентах: MSIE 18% (9%/5%/4%)

MSIE6 только у 4%!