- 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
}
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+162
try {
chrome.tabs.update(tabInfo.tabId, {"active" : true}); // chrome 15+
} catch (e) {
chrome.tabs.update(tabInfo.tabId, {"selected" : true}); // older
}
Это ни капли не говнокод. Это - результат breaking changes в chrome.tabs API, про которое нигде не написали и из-за которого ваши расширения для Chrome, использующие chrome.tabs API могут запросто не работать в относительно старых версиях Chrome. При том, что заявлена поддержка Chrome 9+. Из-за такого странного подхода приходится городить такие конструкции, которые выглядят как непонятный говнокод для непосвященных людей.
guest 26.06.2012 00:39 # 0
Lowezar 26.06.2012 01:22 # 0
У него, кстати, тоже бывают странные глюки с JS, про которые даже консоль молчит... Т.е. ИЕ говорит ошибку, хром говорит ошибку, а ФФ молча ничего не делает. :)
wvxvw 26.06.2012 10:52 # +2
Это как бы не совсем проблема браузера, но все равно не приятно.
TheHamstertamer 26.06.2012 07:48 # +5
>Сотрудники Mozilla Foundation сообщили, что объем кода в Firefox стал слишком большим для работы в 32-разрядной версии Windows. По их словам, проблема заключается в наличии всего 3 Гб максимального виртуального адресного пространства в операционной системе. Один из разработчиков Mozilla Кайл Хьюи (Kyle Huey) отметил: «Похоже на то, что компилятор не работает из-за недостатка виртуального адресного пространства во время фазы оптимизации».
http://blogerator.ru/page/firefox-suxx
HaskellGovno 26.06.2012 08:59 # +1
bormand 26.06.2012 09:03 # +2
Да он скорее всего падает уже на link-time оптимизации.
HaskellGovno 26.06.2012 09:30 # +2
bormand 26.06.2012 09:46 # +4
3.14159265 26.06.2012 17:03 # +2
TarasB 26.06.2012 14:53 # 0
guest 26.06.2012 17:05 # −1
koodeer 26.06.2012 21:03 # −2
HaskellGovno 26.06.2012 21:48 # +2
koodeer 27.06.2012 00:14 # 0
roman-kashitsyn 26.06.2012 22:11 # +2
govnomonad 26.06.2012 09:21 # +1
TheHamstertamer 26.06.2012 09:32 # +3
Lowezar 26.06.2012 10:17 # −7
guest 26.06.2012 10:25 # +5
3.14159265 26.06.2012 14:17 # −3
carsten 26.06.2012 14:23 # −5
3.14159265 26.06.2012 14:31 # 0
http://www.publiz.net/wp-content/uploads/2011/10/evolution-logo-firefox-500x133.jpg
guest 26.06.2012 15:12 # +6
Здрасьте! Вы с другой планеты? Так всегда было!
3.14159265 26.06.2012 19:01 # −2
guest 26.06.2012 13:13 # −10
eth0 26.06.2012 14:51 # +1
TarasB 26.06.2012 14:52 # +3
rat4 26.06.2012 18:41 # 0
TarasB 26.06.2012 18:53 # +1
eth0 26.06.2012 18:55 # +6
bormand 26.06.2012 18:59 # +2
3.14159265 26.06.2012 19:00 # +4
TarasB 26.06.2012 19:00 # +1
eth0 26.06.2012 20:56 # +1
bormand 26.06.2012 19:04 # +8
anonimb84a2f6fd141 27.06.2012 08:33 # +1
bormand 27.06.2012 08:48 # 0
1999 27.06.2012 11:24 # 0
anonimb84a2f6fd141 27.06.2012 11:41 # 0
?
Но с API, конечно, фейл, да.
bormand 27.06.2012 12:16 # 0
anonimb84a2f6fd141 27.06.2012 12:31 # +1
Впрочем, еще остается небольшой шанс, что с другим порядком заработает без try/catch.
1999 27.06.2012 12:50 # 0
wvxvw 27.06.2012 13:17 # +3
bormand 27.06.2012 16:03 # 0
Вот здесь есть хороший холивар на эту тему:
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".
wvxvw 27.06.2012 19:27 # +1
Ну и всякие такие штуки типа object[100] = 100; object["100"] = 100 - и каким по счету станет ключ - хз.
bormand 27.06.2012 19:31 # 0
anonimb84a2f6fd141 27.06.2012 16:32 # 0
Но на всякий случай все равно делалась простая проверка на порядок числовых ключей, и если она не проходила, перезаписывались методы для работы с «очередью».
Но вообще, мне кажется, что с сохранением порядка должно быть быстрее – не надо ничего сортировать. Там же некий список свойств, по идее – знай себе, добавляй в конец.
bormand 27.06.2012 16:43 # 0
Сортировка при обходе, имхо, меньше зло, нежели деградация скорости доступа ко всем хешам, массивам и свойствам объектов.
Хотя хз как оно там в браузерах...
3.14159265 27.06.2012 19:44 # 0
bormand 27.06.2012 19:49 # 0
3.14159265 27.06.2012 19:54 # 0
По сути то же дает отсортированный массив. При добавлении элемента ищем за O(log(n)) куда его поместить, чтобы всё осталось сортированным.
bormand 27.06.2012 20:00 # 0
3.14159265 27.06.2012 20:09 # 0
Ну тогда как указано выше
>При реализации с сохранением порядка или придется держать отдельный список для перебора по порядку
rat4 27.06.2012 12:56 # +2