Недавно ключевой компонент системы поставщика сломался после того, как пользователь применил обновление 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 разрабатывает, создает и внедряет технологические решения для управляющих частными фондами.