Недавно ключевой компонент системы поставщика сломался после того, как пользователь применил обновление Microsoft Windows. Поскольку это один из наших крупнейших клиентов, я чувствовал, что должен сделать все возможное, чтобы решить проблему пользователя. Этот компонент представлял собой HTML-страницу, загруженную внутри клиента Windows, поэтому, естественно, я скопировал исходную ссылку, поместил ее в окно IE и открыл инструменты разработчика. Первое, что меня поразило, это:
DOCTYPE expected. Consider adding a valid HTML doctype.
Возможно, я только начал веб-разработку в то время, когда объявление DOCTYPE было «обязательным», но я был одновременно шокирован тем, что его не было, и очень подозревал, что это может быть проблемой. Я создал дополнительную страницу и добавил DOCTYPE, но это все еще не устранило проблему, поэтому я решил отступить и подождать, пока поставщик выложит исправление/бюллетень.
К концу дня от поставщика так и не поступило никаких известий, а ИТ-отдел клиента не решался откатить обновление Windows, поскольку оно содержало значительные исправления безопасности для IE. Я еще раз взглянул на загрузку страницы в инструментах разработчика IE и заметил, что структура выглядит примерно так:
index.html (provides the bootstrapping) |-> sidebar.html |-> dashboard.html |-> .... other assets ....
Интересно, что боковая панель и информационная панель инициировались index.html, и их HTTP-статус отображался как «прервано». Это также показалось очень подозрительным, поэтому я посмотрел на исходный код страницы index.html и увидел, что оба ресурса загружаются в IFrames. Я не эксперт по IFrame, но я знаю, что они причудливые, поэтому быстрый тест на то, что страница sidebar.html будет загружаться напрямую (тест прошел успешно), подтвердил, что мы на правильном пути. Быстрый поиск в Google IFrame, не загружающихся в IE, привел к отсутствию еще одного элемента на странице:
<meta http-equiv="X-UA-Compatible" content="IE={IE_VERSION_HERE}">
Добавление этого тега с IE=edge позволило нормально загрузить страницу, хотя выглядело это немного странно. Несмотря на немного измененный макет, страница была полностью функциональной. Теперь у нас есть исправление, поэтому мы можем подождать, пока поставщик не посоветует «настоящее» исправление.
У меня была возможность узнать, что причина, по которой макет все еще был немного изменен, заключалась в том, что поставщик ранее пытался заставить IE отображать в режиме IE7, и поскольку это не работает после этого обновления, мы, очевидно, получаем другое представление с включен режим "край".
Как мы можем улучшить
Настоящая проблема здесь не в том, что Центр обновления Windows сломал часть кода. Дело в том, что в течение примерно 10 лет этот поставщик заставлял Internet Explorer отображать свои страницы, используя устаревший режим отображения. Несмотря на каждый новый выпуск IE, поставщик позволял ему становиться все хуже и хуже, пока однажды обновление Windows не сломало его. Возможно визуал:
|---IE7---| |---------|---IE8---| |---------|---------|---IE9---| |---------|---------|---------|---IE10---| |---------|---------|---------|----------|---IE11---| |<<<<<<<<<<<<<<<<<<<<<10 years>>>>>>>>>>>>>>>>>>>>>>|
Отсутствие изменений при выпуске IE8 было, по крайней мере, понятно. Но когда был выпущен IE9, некоторые мигающие индикаторы и сигналы тревоги должны были погаснуть и сказать: «Нам нужно обновить части этого кода, которые зависят от IE7, потому что теперь мы отстаем на две версии». Мы не можем относиться к обратной совместимости как к данности… вместо этого мы должны относиться к ней как к подарку, который дает нам немного времени для обновления кода, требующего обратной совместимости.
Адам Алесандро является основателем и генеральным директором Signalbase, Inc. Signalbase разрабатывает, создает и внедряет технологические решения для управляющих частными фондами.