Don't forget to test your web site/application in private browsing (incognito) mode

From time to time one or another web site or web application (SPA, PWA whatever word is now trendy) faces that problem: it throws errors and does not work when private browsing mode is turned on. Real-world examples: Google+ signin, Amazon Cognito Identity SDK.

Here is more-or-less correct and complete list of things that don't work when private browsing (incognito mode) is turned on:

• Safari 10 and below: localStorage and sessionStorage API is present, but throws a DOMException.QUOTA_EXCEEDED_ERR when the code is trying to write something. Fixed in Safari 11
• IE10+/Edge: indexedDB is undefined
• Firefox: indexedDB is undefined

A similar situation may happen when the user has disabled cookies/data, e.g. in Chrome/Chromium: Settings -> "Show advanced settings..." -> "Content settings..." -> "Block sites from setting any data".

• Chrome/Chromium: cookies, localStorage, sessionStorage and indexedDB are disabled. Will throw "Uncaught SecurityError: Access to 'localStorage' is denied for this document".
• Firefox: cookies, localStorage, sessionStorage
• IE: cookies

And one more restriction exists in Safari when JavaScript is in strict mode: modification of error object may be forbidden (both overwriting existing property and adding a new one) and may throw

https://stackoverflow.com/questions/2860879/detecting-if-a-browser-is-using-private-browsing-mode/41322183#41322183

Глубина стека JavaScript (дубль 3)

Продолжение (первая часть, вторая часть)

Баг в Firefox подсказал, что глубина стека зависит ещё и от метода вызова (fn(), fn.call(), fn.apply()), и от контекста функции (fn.call(null) или fn.call(this)), и от платформы (Firefox 39/Win vs. Firefox 39/Linux). В одном из комментариев было указано, что при переходе с прямого вызова fn() на fn.call() в версии Firefox под Linux глубина стека уменьшалась с 7000 до 500.

Добавил в скрипт подсчёт глубины стека при использовании call.

Результаты

Windows 7 64-bit:
Chrome 44:    глубина стека не зависит от метода вызова
Safari 5.1.7: глубина стека не зависит от метода вызова
IE11:         fn() 2800..2300, fn.call() 1900..1700
Firefox 39:   fn() 8400..4800, fn.call() 7200..5600

Windows 10:
Edge:         fn() 5000,80026..81336, fn.call() 5207..5291
Firefox Dev. edition 43.0a2: fn() 3500..3000, fn.call() 4400..3300

Интересные факты:

• В Firefox/Win при отсутствии передаваемых аргументов прямой вызов fn() иногда занимает меньше памяти в стеке, чем fn.call(this), при наличии аргументов - всегда fn.call(this, arg) занимает меньше, чем fn(arg).
• В Firefox/Linux fn.call() в некоторых случаях даёт на порядок меньшую глубину стека.
• В IE11 fn.call() даёт в 1.3 - 1.4 раза меньшую глубину стека.
• В Edge первый запуск может дать глубину стека fn() около 5000, последующие запуски дают глубину стека около 80000

Глубина стека JavaScript (дубль 2)

Продолжение (первая часть здесь).

На http://www.2ality.com/2014/04/call-stack-size.html натолкнулся на мысль, что измеряемая глубина стека зависит от размера фрейма (который может зависеть от локальных переменных и аргументов функции). Дополнил скрипт, заодно для наглядности вставил рисование графика глубины стека в зависимости от количества аргументов/локальных переменных. Результат:

Кол-во
аргументов/     0/0    1/0    1/1    1/2    1/3
переменных

Chrome 39:      41962  31472  27975  25178  22889  ±50
Chrome 36:      20986  15740  13991  12592  11447  ±50
Safari 5.1.7:   65532  58250  52425  47659  43688
Opera 12.17:    32624  31505  32691  31478  31419
Opera 17:       21002  15752  14002  12602  11456  ±50
IE9 (IETester): 24789  20657  20657  20657  20657
IE11:           32000..62000 не зависит от кол-ва переменных
Firefox 20:     27000..52000 не зависит от кол-ва переменных
Firefox 31:      6600..21000 не зависит от кол-ва переменных

Результаты для IE11 и Firefox не зависят от количества локальных переменных/аргументов, и сильно изменяются от запуска к запуску.

Результаты для Chrome и новой Opera незначительно изменяются после первого запуска, далее остаются постоянными.

Эффективность реализации алгоритма reflow (layout) в браузерах

Реализация shadow DOM была удалена из кода WebKit, чтобы переписать её заново в отдельной ветке. По замыслу авторов это должно позволить

1. избавиться от устаревшего кода, который много раз менялся вместе с изменениями спеки
2. контролировать влияние на производительность (постепенные изменения кода в течение нескольких лет дали в итоге замедление времени загрузки страницы на 5%, но измерить результат было сложно, теперь сравнивать производительность разных веток кода будет проще)

> The old implementation on trunk resulted in 5% overall slowdown in the page load time but we didn't quantify that until we removed the feature entirely last year.  That's probably because the feature was added over years as a pile of small changesets each of which introduced immeasurably small performance regressions.  Development in a branch allows a faithful performance comparison between the two.

> JSC team has been utilizing SVN branches to work on Concurrent JIT, Generational GC, FTL, etc... to quantity the total performance cost and benefit of each feature, and it has been working very well as far as I could tell.

Порядок перечисления в for-in и Object.keys()

ECMAScript Language Specification Edition 3 (ECMA-262-3):

• 4.3.3 Object
  An object is a member of the type Object. It is an unordered collection of properties each of which contains a primitive value, object, or function.
• 12.6.4 The for-in Statement
  The mechanics of enumerating the properties (get the name of the next property ... that doesn't have the DontEnum attribute) is implementation dependent.

ECMAScript Language Specification Edition 5.1 (ECMA-262-5.1):

• 8.6 The Object Type
  An Object is a collection of properties.
• 12.6.4 The for-in Statement
  The mechanics and order of enumerating the properties (let P be the name of the next property of obj whose [[Enumerable]] attribute is true) is not specified.
• 15.2.3.14 Object.keys ( O )
  If an implementation defines a specific order of enumeration for the for-in statement, that same enumeration order must be used in step 5 of this algorithm.

IE document/browser modes

http://jsfiddle.net/7ZE7M/

IE9:
http://i.stack.imgur.com/yzXVq.png

IE10:

• navigator.appName: Microsoft Internet Explorer
• navigator.userAgent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/6.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E)
• document.compatMode: CSS1Compat
• document.documentMode: 10

IE11:

• navigator.appName: Netscape
• navigator.userAgent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; rv:11.0) like Gecko
• document.compatMode: CSS1Compat
• document.documentMode: 11

Максимальная длина массива в Function.prototype.apply

MDN предупреждает, что максимальная длина массива, передаваемая в Function.prototype.apply, ограничена (порядка 10^4). Меня заинтересовали точные значения, которые я определяю вот таким скриптом.

Глубина стека JavaScript в разных браузерах

Скрипт для измерения глубины стека и результаты (получены на одном компьютере, Windows 7 SP1, 64-bit):

Chrome 28:      20966 - 21000, не зависит от количества открытых вкладок
Firefox 20:     26000 - 50000, сильно изменяется от измерения к измерению
Firefox 22:     38000 - 53000, сильно изменяется от измерения к измерению
Opera 12.16:    32629, не зависит от количества открытых вкладок
Opera 15:       20968, не зависит от количества открытых вкладок
IE10:            2946 - 2947, не зависит от количества открытых вкладок, включения/выключения отладки JavaScript, выбора Browser Mode/Document Mode
IE9 (IETester): 20670, не зависит от количества открытых вкладок

IE8 (IETester):  1472 - 1475, не зависит от количества открытых вкладок

IE7 (IETester):  2546 - 2548, не зависит от количества открытых вкладок

IE6 (IETester):  2546 - 2548, не зависит от количества открытых вкладок

Результаты для IE на разных компьютерах различаются на два порядка, на одной из машин в IE9 была получена глубина стека 42329, на другой для IE8 (IE9 downgraded to IE8) было всего 276 (!).

Поддержка браузерами субпиксельных размеров

Согласно спецификации CSS2 размеры элементов в пикселях могут быть дробными, например #id {width: 100.5px;}. Некоторые браузеры не поддерживают субпиксельные размеры, усекая их до меньшего целого числа. Как написать feature test (во время загрузки страницы определить, поддерживает ли браузер субпиксельные размеры)?

События resize и mouse wheel в разных браузерах

Опять экспериментирую с fixed headers (это такие хитрые скрипты, которые фиксируют заголовок таблицы или текста у верхней границы экрана при прокрутке вниз, в интернетах существует много вариантов, но мне ни один не подходит - они все работают только на прокрутку окна браузера, а у меня длинная таблица внутри div со стилем overflow:auto). Все браузеры имеют свои особенности при генерации интересующих меня событий изменения размера окна (resize) и вращения колеса мыши (mousewheel).

IFRAME: перезагрузка

Встала задача подключить чужую страничку в модальном окне внутри своего приложения (то есть надо посмотреть карту - показали окно с картой, не надо - спрятали). Не мудрствуя лукаво, использовал IFRAME, и тут же напоролся на Firefox и WebKit.

Тонкости split() в IE

Чисто случайно (впрочем, как обычно это и происходит) при разборе на стороне клиента CSV-подобного ответа сервера обнаружил различие в результатах String#split(RegExp) и String#split(String) в Internet Explorer 6, 7 и 8 версий (в 9 и 10 не проверял):

"1||2".split(/\|/) // вернёт ["1", "2"]
"1||2".split("|")  // вернёт ["1", "", "2"]

То есть при вызове split с регулярным выражением осёл IE считает подряд идущие совпадения одним совпадением и пустых элементов в результате не возвращает, в отличие от вызова split с использованием строки. Во всех остальных браузерах split возвращает одинаковые результаты (с пустыми элементами).