- 1
- 2
- 3
- 4
- 5
try {
chrome.tabs.update(tabInfo.tabId, {"active" : true}); // chrome 15+
} catch (e) {
chrome.tabs.update(tabInfo.tabId, {"selected" : true}); // older
}-
JavaScript / Говнокод #11297
+162
Это ни капли не говнокод. Это - результат breaking changes в chrome.tabs API, про которое нигде не написали и из-за которого ваши расширения для Chrome, использующие chrome.tabs API могут запросто не работать в относительно старых версиях Chrome. При том, что заявлена поддержка Chrome 9+. Из-за такого странного подхода приходится городить такие конструкции, которые выглядят как непонятный говнокод для непосвященных людей.
Запостил:
1999,
25 Июня 2012
Follow us!
У него, кстати, тоже бывают странные глюки с JS, про которые даже консоль молчит... Т.е. ИЕ говорит ошибку, хром говорит ошибку, а ФФ молча ничего не делает. :)
Это как бы не совсем проблема браузера, но все равно не приятно.
>Сотрудники Mozilla Foundation сообщили, что объем кода в Firefox стал слишком большим для работы в 32-разрядной версии Windows. По их словам, проблема заключается в наличии всего 3 Гб максимального виртуального адресного пространства в операционной системе. Один из разработчиков Mozilla Кайл Хьюи (Kyle Huey) отметил: «Похоже на то, что компилятор не работает из-за недостатка виртуального адресного пространства во время фазы оптимизации».
http://blogerator.ru/page/firefox-suxx
Да он скорее всего падает уже на link-time оптимизации.
http://www.publiz.net/wp-content/uploads/2011/10/evolution-logo-firefox-500x133.jpg
Здрасьте! Вы с другой планеты? Так всегда было!
?
Но с API, конечно, фейл, да.
Впрочем, еще остается небольшой шанс, что с другим порядком заработает без try/catch.
Вот здесь есть хороший холивар на эту тему:
http://code.google.com/p/v8/issues/detail?id=164
Как раз о том, что многие считают искажение порядка (даже для числовых индексов, при сохранении порядка индексов строковых!) багом. Несмотря на то, что в спецификациях EcmaScript явно сказано, что ни о каком порядке не может быть речи: "The mechanics and order of enumerating the properties (step 6.a in the first algorithm, step 7.a in the second) is not specified".
Ну и всякие такие штуки типа object[100] = 100; object["100"] = 100 - и каким по счету станет ключ - хз.
Но на всякий случай все равно делалась простая проверка на порядок числовых ключей, и если она не проходила, перезаписывались методы для работы с «очередью».
Но вообще, мне кажется, что с сохранением порядка должно быть быстрее – не надо ничего сортировать. Там же некий список свойств, по идее – знай себе, добавляй в конец.
Сортировка при обходе, имхо, меньше зло, нежели деградация скорости доступа ко всем хешам, массивам и свойствам объектов.
Хотя хз как оно там в браузерах...
По сути то же дает отсортированный массив. При добавлении элемента ищем за O(log(n)) куда его поместить, чтобы всё осталось сортированным.
Ну тогда как указано выше
>При реализации с сохранением порядка или придется держать отдельный список для перебора по порядку