На прошлой неделе выкатили Safari 16.4, и для нас это стало кошмаром. Мы разрабатываем браузерное приложение для создания игр под названием Construct. Ранние версии Safari 16.4 ломали открытие проектов, предпросмотр проектов и весь контент, опубликованный при помощи Construct, каждый раз по-разному. Я захотела поделиться своим опытом, чтобы пользователи, разработчики, регуляторы и сама Apple знали, через что нам пришлось пройти из-за, казалось бы, рутинного релиза Safari.
Разработчики большинства браузеров предоставляют предрелизные версии для предварительного тестирования. Например, ежедневно обновляются Chrome Canary и Firefox Nightly, кроме того, существуют более редкие dev- и beta-релизы. Apple предоставляет Safari Technology Preview (STP), но она совместима только с macOS, и не обновляется по какому-нибудь открыто опубликованному графику. Похоже, это происходит примерно раз в две недели. Предрелизные браузеры обычно довольно шероховаты и содержат очевидные проблемы, которые достаточно быстро устраняют. Однако когда они начинают переходить в состояние беты, необходимо присмотреться повнимательнее. Поэтому когда 16 февраля было заявлено о выпуске Safari 16.4 beta 1 (тоже без какого-либо публичного графика), мы начали присматриваться и обнаружили множество проблем.
Сбои открытия проектов
Проекты Construct хранятся в файлах zip; для их считывания мы используем популярную библиотеку zip.js, которая, в свою очередь, использует Compression Streams API (если он поддерживается). В Safari 16.4 добавили поддержку Compression Streams API, однако она почему-то оказалась несовместимой с zip.js, поэтому открытие проектов в Construct завершалось сбоями. Потенциально это означает, что многие случаи применения zip.js в вебе тоже поломаны.
Я надлежащим образом отправила issue 17 февраля. После неразберихи с тем, была ли эта issue дубликатом другой (она не была), инженеры Apple изучили и выявили проблему, после чего сказали, что её устранят к 27 февраля. В конечном итоге, неплохой ответ, к чести сотрудников Apple.
Затем 8 марта вышел Safari Tech Preview 165. В нём по-прежнему присутствовал баг. Релиз Safari 16.4 казался близким, но мы не знали точно, потому что его график был неизвестен. Что нам делать? Они внесли изменение, но проблема сохранилась? Или исправление ещё не внесено? Но почему они так поступили, если после исправления прошло уже больше недели? Должны ли мы предположить, что Safari будет выпускать сломанные потоки сжатия, и выпустить аварийный патч, чтобы обойти эту проблему? Они ведь не будут рисковать тем, что сломают для всех zip.js? Даже если мы это сделаем, мы не знали, сколько у нас осталось времени. Должны ли мы вместо этого ничего не делать и надеяться, что Safari 16.4 выпустят с работающим исправлением? Но тогда мы не узнаем, произойдёт ли катастрофа, пока версию браузера не выкатят. Это ужасная дилемма.
Я спросила, будет ли выпущено исправление в Safari 16.4, но инженер ответил мне про STP. К сожалению, это не было ответом на вопрос: нет никаких конкретных гарантий, что присутствующее в STP перейдёт в Safari 16.4.
В конечном итоге мы решили посмотреть, с чем выйдет Safari 16.4. Следует учесть, что во время событий, описанных в этом посте, мы не могли открывать большинство проектов в Construct. Также учтите, что единственный способ узнать, что же реально выпустят в версии браузера — это просто вручную тестировать каждый релиз Safari, то есть нам придётся тратить время на выяснение того, что Apple уже наверняка знает. После пары недель мучительного ожидания 23 марта вышел STP 166, а затем 27 марта наконец-то выкатили Safari 16.4. Между ними был всего один рабочий день. Что я могла сделать за этот день? Ничего: на пятницу и всю следующую неделю я взяла отпуск. Я никак не могла узнать, когда брать отпуск в свободное от релиза Safari время, потому что публичный график релизов отсутствует. Поэтому лично проверить, всё ли работает, я могла не раньше 3 апреля, через целую неделю спустя после всемирного релиза Safari 16.4. До этого момента я не могла быть полностью уверена, что наше ПО будет работать в Safari. К счастью, оно работало. Оно работало и в STP 166, хотя эта информация и не особо полезна.
Всех этих трудностей во многом можно было избежать, если бы Apple просто указала для issue версию, в которой она исправлена, как это делают другие разработчики браузеров. Небольшая доля прозрачности существенным образом изменила бы наше планирование.
Сломанный предпросмотр проектов
Следующей обнаруженной проблемой стало то, что предпросмотр проектов в Construct просто показывал пустой экран. Упс! Это тоже серьёзная проблема для нас. Я снова отправила issue. Инженеры Apple снова помогли в изучении и проделали хорошую работу. Я опущу подробности, потому что они очень сложны и не особо относятся к делу. Если вкратце, Service Worker важны для предпросмотра проектов в Construct, а мы случайно использовали баг Chrome, из-за чего наш Service Worker оказался поломанным в Safari 16.4. То есть в этом случае в проблеме на самом деле был виновен Google (Google, пожалуйста, устраните её), и решить её должны были мы.
Снова возникла ужасная дилемма, но на этот раз хуже: казалось, релиз Safari уже близок. На этот раз проблему определённо нужно решать нам. Сколько у нас есть времени? Это важный вопрос. У нас есть собственный график релизов Construct с бета-релизами для тестирования и стабильным релизом каждую пару месяцев, который мы выкатываем для всех. Если бы мы знали дату релиза Safari, то смогли бы сравнить графики. Если время есть, можно расслабиться и уделить время исследованию, а наше исправление попадёт к пользователям по обычному графику релизов до апдейта Safari. Но если Safari выпустят на следующий день, налицо экстренная ситуация: Construct поломан и мы должны исправить его до завтра, чтобы избежать недовольства пользователей! В этом и заключается разница между рутинным багом и экстренной ситуацией.
Разумеется, мы понятия не имели, что Safari не запланирована для релиза на следующий день. Некоторые сотрудники Apple пытались намекнуть нам о расписании, которого, очевидно, не могли раскрывать, но нам не удалось добиться ничего более конкретного, чем «скоро». Поэтому мы были вынуждены считать это экстренным случаем и действовать соответственно. Усугубляло ситуацию то, что разработка при помощи Service Worker сложна, у них есть различные трудности, из-за чего их сложнее кодить. Поэтому нам пришлось забросить другую работу, проделать сложную работу по экстренному графику, а затем сразу же выкатить её всем пользователям, что рискованно: что, если мы где-то ошиблись и сломали что-то другое?
Всего этого хаоса можно было бы избежать, если бы Apple просто опубликовала график релизов, как это делает каждый разработчик браузеров. Снова небольшая доля прозрачности позволила бы нам избежать множества проблем. К счастью, всё прошло хорошо и мы не сломали ничего другого, однако у нас возникла новая головная боль: похоже, Safari кэшировала старый скрипт Service иначе, чем другие браузеры. Я так и не разобралась, почему это происходило, но это создавало риск серьёзного ухудшения ситуации.
В конечном итоге, Safari 16.4 выкатили примерно месяц спустя. Мы могли бы работать спокойно. Экстренные действия были не нужны и оказались пустой тратой времени.
Поломан весь контент, опубликованный в Construct
Среди всего этого я упустила ещё более серьёзную проблему. Оказалось, что в Safari 16.4 все веб-игры, опубликованные Construct за последние несколько лет, оказывались сломанными.
Проблема заключается в том, что Construct использует OffscreenCanvas (если он доступен), чтобы выполнять игру в Web Worker для улучшения характеристик производительности. В Safari 16.4 добавили поддержку OffscreenCanvas, но только контекст
"2d" — поддержки WebGL по-прежнему не было. Для рендеринга Construct требуется WebGL. Поэтому он видел, что OffscreenCanvas поддерживается, создавал воркера, создавал OffscreenCanvas, затем получал null для контекста WebGL, после чего происходит сбой и пользователь видел пустой экран. На самом деле, это была самая крупная проблема из всех. Из-за него ломался весь объём имеющегося веб-контента. Мы выпустили второй экстренный патч для исправления (снова пройдя через все эти хлопоты), но поскольку этот контент публиковался нашими пользователями по всему вебу в течение нескольких лет, обновлять его было практически невозможно. Он охватывал тысячи игр на сайтах наподобие itch.io, Newgrounds, Poki и нашем собственном; обучающие материалы, используемые компаниями; образовательные материалы, используемые учителями; интерактивные киоски в музеях… и так далее. Это всё ещё оставалось потенциальной катастрофой.Это застало нас врасплох. Мы распознавали OffscreenCanvas, просто проверяя, задан ли он (то есть
typeof OffscreenCanvas !== "undefined"). Я не ожидала, что браузер выпустят с частью контекстов, и предполагала, что он будет иметь равенство со стандартным элементом <canvas>. Почему бы этому не быть? В документации MDN ничего не говорится о несогласованной доступности контекстов. В 2018 году Chrome выпустил OffscreenCanvas со всеми контекстами. В 2022 году Firefox выпустил OffscreenCanvas со всеми контекстами. Впервые браузер выпустил несогласованную поддержку контекстов.Apple заявила, что это, очевидно, допускается спецификацией, и что функциональность распознаётся ошибочно с нашей стороны. Прочитав соответствующую спецификацию, я всё ещё не могу сказать, будучи веб-разработчиком, а не программистом браузеров, очевидно ли то, что это допустимо. Но допустим, что так и есть, в конце концов, разработчики браузеров дольше изучают спецификации, чем большинство веб-разработчиков.
Во-первых, насколько я понимаю, цель спецификаций — сохранение веб-совместимости: в HTML Design Principles говорится, что нужно поддерживать существующий контент. Например, когда выяснилось, что имя нового метода
flatten Array ломает веб-сайты, в спецификации его переименовали во flat, чтобы он ничего не ломал. Это демонстрирует, что спецификация отражает реальность веба, а не является оправданием её нарушения. Поэтому предлагаемое мной решение заключалось бы в том, что необходимо изменить спецификацию, указав в ней, что HTML canvas и OffscreenCanvas должны поддерживать одинаковые контексты. Это позволяет избежать проблемы веб-совместимости, с которой мы столкнулись (и, возможно, столкнулись остальные), да и во всём остальном кажется более целостным. Safari тогда следовало отложить реализацию OffscreenCanvas до того, как появится поддержка WebGL, и тогда бы весь соответствующий веб-контент продолжил работать.Во-вторых, даже если спецификация признана корректной и авторы решат отказаться от её изменения, разве Apple не волнует веб-совместимость? Почему бы не отложить выпуск OffscreenCanvas, вне зависимости от того, что написано в спецификации? Это было бы прагматичным решением для повышения веб-совместимости. Можно было перенести релиз и потратить время на добавление поддержки WebGL. Я уверена, что большинство опытных разработчиков ПО делало что-то подобное за свою карьеру: на поздних этапах обнаружена проблема с новой фичей, поэтому ты отключаешь фичу, откладываешь её выпуск на следующий релиз по графику и тратишь освободившееся время на её правильную реализацию. Safari выпустила OffscreenCanvas на четыре года и шесть месяцев позже выпуска его полной поддержки в Chrome, но он при этом ломает большую часть контента; наверно, было бы лучше выпустить его четыре года и девять месяцев спустя после Chrome с полной реализацией, сохраняющей веб-совместимость? Зачем выбирать поспешный вариант, который что-то ломает? Я приложила максимум усилий, чтобы убедить Apple отложить выпуск, но мне просто расплывчато ответили, что фича, вероятно, будет выпущена без изменений.
На мой взгляд, это пример того, как Apple использует формальность, чтобы не менять свой график. Мы столкнулись с катастрофой, и чтобы избежать её, Apple достаточно было отложить выпуск одной из множества новых фич Safari 16.4. В конечном итоге, разработчики добавили специальную браузерную хитрость, обнаруживающую наш движок и отключающую для него OffscreenCanvas. Это действительно позволило нам избежать катастрофы с совместимостью. Однако всем остальным, кто сделал ту же ошибку, не повезло — хак браузера специально для нашего движка не спасёт их.
Личное примечание
В обычной ситуации я бы этого не сказала, но мне кажется, важно подчеркнуть масштаб проблемы. Лично для меня это были невероятно напряжённые несколько недель. Иногда меня тошнило от беспокойства, в том числе и вне работы. Неопределённость сводит с ума: возможно, произойдёт катастрофа, а может быть, всё будет в порядке. Я не знаю, что произойдёт, и не знаю, когда мы об этом узнаем. Каждый день в течение нескольких недель мог стать обычным днём или обернуться катастрофой, и мы никак не могли узнать, каким он будет, и даже не знали, какая из многочисленных потенциальных проблем будет причиной катастрофы. И хотя обычно всё не так плохо, предыдущие релизы Safari тоже вызывали подобные проблемы.
Мы всего лишь люди, и подобные ситуации влияют на нас. Должна сказать, что строила эту компанию более десятка лет, от работы на ноутбуках дома до успешного бизнеса с 250 тысячами активных пользователей ежемесячно. Я сталкивалась с катастрофами, критикой, недовольными пользователями, внезапными неожиданными сбоями серверов по праздникам, и так далее. Это может быть непросто, но ты справляешься с этим, как профессионал. Однако ситуация с релизом Safari стала одной из худших и самых стрессовых рабочих ситуаций. И самое раздражающее заключается в том, что всего этого можно было избежать: Apple могла бы внести очень простые изменения, избавившие бы нас от большей части стресса, однако она годами постоянно не вносит такие изменения.
Хочу подчеркнуть, что это не критика каких-то конкретных сотрудников Apple. Ни один человек из Apple не стал причиной этого стресса — я специально сказала, что многие из них хорошо делают свою работу, и у Apple нет недостатка в умных и трудолюбивых людях. Проблема заключается в политиках управления релизами Apple. Такие аспекты, как полное отсутствие прозрачности, вызывают большую долю неопределённости, и мне кажется, что именно эти корпоративные политики ответственны за стресс, которому подвергаюсь я и, вероятно, другие веб-разработчики. Моя единственная цель здесь в том, чтобы осветить реальность, с которой сталкиваются разработчики при работе с релизами Safari, и в том, чтобы попытаться повлиять на изменения в политиках Apple, которые, по моему мнению, влияют на это.
История релизов Apple
Релизы Safari обычно не настолько плохи, однако подобные вещи случались в прошлом и тоже вызывали большой стресс и хаос. Это показывает, что ничего не поменялось, и на самом деле ситуация даже усугубляется. Вот краткое описание предыдущих проблем, которые у нас возникали с Safari.
- iOS 11.2.2 ломала WebAssembly. Она ломала отдельные части Википедии, весь опубликованный контент Construct, а может, и что-то ещё. Большой части проблем можно было избежать простым отключением WebAssembly, чтобы всё откатилось к fallback. Вместо этого компания оставила его включённым, но поломанным до релиза iOS 11.3 несколькими месяцами позже. Тем временем Apple не предоставляла никакой существенной поддержки. Мы получили помощь только от инженера Википедии, который поделился обходным решением, которое они обнаружили.
- Safari 11.1 сломала MessageChannels таким образом, что это поломало Construct, из-за чего нам пришлось годами поддерживать обходные решения.
- Safari 14 выпущена с поломанным методом replaceChildren(), вызывавшим глитчи в Construct.
- Safari 14 поломала localStorage, а затем поломала IndexedDB
- Даже когда проблемы устраняются, это всё равно может вызывать стресс и неопределённость. Проблема с аудио в Safari 15 создавала риск поломки воспроизведения аудио во всём контенте Construct. Она была устранена до полного релиза Safari 15, но заранее Apple этого никак не подтверждала. Мне снова пришлось проверять всё самой.
- Баг с WebGL в Safari 15.0-15.4 приводил к рендерингу пустого экрана для части контента Construct. Проблему устранили в Safari 15.5, но нам так об этом и не сообщили, мы выяснили это, вручную проверяя каждый релиз Safari.
- Годами мы мечтали об едином открытом формате аудиофайлов, который воспроизводится во всех браузерах. WebM Opus почти готов: он поддерживается всеми браузерами, в том числе и Safari на macOS, но не поддерживается только в Safari на iOS и iPadOS. Это единственное препятствие для использования этого формата во всех браузерах, которое бы устранило существенные затруднения с поддержкой аудио в вебе. Однако непонятно, работает ли Apple над этим вообще; я создала issue примерно год назад, но чётко о намерениях компании так никто и не сказал.
- В Safari 16 есть проблема, в некоторых ситуациях ломавшая воспроизведение аудио в Construct. Похоже, никакого существенного ответа от Apple на неё не было, несмотря на то, что отчёт отправлен примерно полгода назад. Мы по-прежнему поддерживаем обходное решение, тоже вызывающее другие затруднения.
- Иногда issue пропадают в пустоту. Эта issue была отправлена около года назад, но вразумительной реакции от Apple не было. Сравните это с тем, как реагировали на схожую проблему Firefox, отчёт о которой был передан примерно в то же время.
Без сомнения, есть и другие случаи, список ни в коем случае не исчерпывающий. Во многих из issue, на которые представлены ссылки выше, происходит нечто схожее: непонятность происходящего, неотвеченные вопросы о графиках, отказы Apple раскрывать нужные разработчикам подробности.
Такие серьёзные проблемы возникают у нас только с Apple и Safari. Редко появляются подобные затруднения с какими-то другими разработчиками браузеров, а когда они возникают, то есть полная прозрачность относительно того, что с ними будут делать, так что мы можем строить планы.
Как решить эту проблему
Вкратце ответ будет таким: «поступайте так же, как другие разработчики браузеров». Ни один другой разработчик браузеров не создаёт таких серьёзных проблем, и по большей мере это вызвано их гораздо более совершенными процессами разработки для веб-разработчиков наподобие нас. Они включают в себя:
- Прозрачность: говорите разработчикам, в каких релизах будут выпускаться исправления багов, и публикуйте график релизов. Одно это позволит избавиться от огромной доли неопределённости.
- Обновляйте Safari независимо от ОС: Safari — единственный оставшийся браузер в отрасли, привязанный к своей ОС. Это ставит высоченный барьер перед обновлением Safari. Похоже, даже небольшой, но критичный апдейт вынужден ожидать следующего апдейта всей системы. Разумеется, это увеличивает время решения даже серьёзных проблем: вместо недель или дней требуются месяцы. Если бы команда разработки Safari контролировала собственный цикл релизов и разумно им управляла, то это существенно снизило бы влияние подобных проблем.
- Больше предрелизных опций тестирования: нужен эквивалент Chrome Canary и Firefox Nightly, обновляющийся ежедневно и независимо от ОС, способный быстро итеративно решать проблемы и подтверждать их устранение. И такая версия, и STP также должны быть доступны на iOS и iPadOS, поскольку сейчас единственный способ тестирования предрелиза Safari на iOS — это полный апдейт до бета-системы, что медленно и неудобно.
- Коммуникация: ошибки иногда случаются, и если проблемы вызваны поломками в Safari, Apple должна сообщать всем, что происходит, что она делает с этим, когда ожидается решение и что пока могут делать разработчики. Чаще всего ответом становится тишина, из-за чего складывается ощущение, что компании попросту плевать. Я подозреваю, что сотрудники Apple заботятся о решении проблем, но снаружи это часто выглядит плохо.
По моему опыту, все остальные разработчики браузеров справляются с этим очень хорошо. С этими четырьмя пунктами не справляется только Apple. Выпуск новых фич для Safari — хорошее дело, потому что Apple, похоже, сосредоточена на Safari 16.4, но не делает ничего для реализации пунктов списка.
Заключение
В конечном итоге всё заработало. Но посмотрите на те усилия, которые нам пришлось предпринять просто для того, чтобы всё продолжило работать после рутинного релиза Safari. Возможно, со следующим релизом нам предстоит пройти через всё это снова, и со следующим после него тоже, и есть вероятность того, что рано или поздно кто-то что-то пропустит и мы снова столкнёмся с катастрофой… и когда я думаю об этом, меня снова начинает подташнивать.
Я хотела бы любить Safari. В нём используются отличные технологии. В последнем релизе выпущено множество крутых фич, от которых в обычных условиях я была бы в восторге. Очевидно, что у компании нет недостатка в талантливых сотрудниках, способных быстро разобраться в подробностях технической проблемы, и я хочу чётко заявить, что у меня нет никаких личных проблем ни с кем из Apple. Печально то, что я боюсь релизов Safari. Apple совершенно точно могла бы сделать их гораздо лучше. Процесс релизов ужасно поломан и оставался таким несколько лет. Во многих случаях сложности можно было бы устранить лишь небольшим вмешательством Apple. Однако компания упорно придерживается одного процесса и никогда не проявляла интереса в его изменении. А разработчики вроде меня проходят через ад разработки, решая возникающие в результате этого проблемы: необязательное нарушение нормальной работы, трата времени на выяснение того, что Apple уже знает, но не говорит нам, ощущение стресса и неопределённости из-за надвигающихся катастроф без возможности узнать, когда и что случится. На мой взгляд, это выглядит как политика пренебрежения разработчиками.
Я отчаянно хочу, чтобы Apple менялась. Я хочу, чтобы Safari был прекрасным браузером. Я хочу разрабатывать потрясающий контент, превосходно работающий в Safari. Я хочу обеспечивать сильную конкуренцию браузеров ради совершенствования веба. Откровенно говоря, я хочу, чтобы Apple поменялась и ради моего ментального здоровья. Если Apple не поменяется, то единственное, что мне останется — это уговаривать людей переходить на Chrome или Firefox и просить регуляторов заставить компанию поменять отношение. Несмотря на недавнюю юридическую активность, мне кажется, этот релиз показывает, что проблемы с релизами Safari усугубляются, а не уменьшаются; тем временем, Apple, похоже, больше заинтересована в борьбе с требованиям, чем в решении этих проблем. В конечном итоге мы окажемся в монокультуре Chromium, что будет плохо для веба и принесёт собственные проблемы. Но если это произойдёт, то я должна сказать, что на этом этапе я ни капли не буду жалеть об отсутствии необходимости иметь дело с релизами Safari.
