Например, он всегда скачивает последнюю версию, и после скачивания автоматически запускает установщик. А в случае обрыва соединения он может перезапустить закачку.
.app — это, вроде бы, папки, разве нет? А «файлы» — это *.dmg
перезагружать Finder не знаю, зачем, но, может быть, чтобы иконки обновить.
Если «сносить профиль» помогает, но все терять не хочется, то можно попробовать «снести» только половину профиля, и определить, в какой половине лежит проблема (перед сносом сохранить бэкап, конечно). Потом из «проблемной» половины убрать еще половину. И так далее, пока дело не дойдет до отдельного файла. Дальше открыть файл и так же найти «виновную» строчку/запись и удалить ее. Еще можно составить баг репорт: «Опера крешится при такой-то записи в таком-то файле».
Большинство старых костылей, действительно, не нужно — т.к. они работали с «особенностями» движка. Теперь проблемы другие — вызванные, в основном, названием браузера. Например, на одном сайте раньше было: if( navigator.userAgent.match('Opera') ){ код для Presto}
А теперь (когда веб-дизайнер узнал, что у нас в строке User-Agent теперь стоит OPR вместо Opera) стало: if( navigator.userAgent.match('Opera') || navigator.userAgent.match('OPR') ){ код для Presto}
…
Или «белые списки» user-agent'ов, в которые Оперу забывают включить.
Или считают, что если в строке user-agent упомянут Хром — это значит, что в браузере есть поддержка mp3, H264, PPAPI, NaCl, и т.п. (пользователи Хромиума от этого тоже страдают, да)
Таких подробностей не знаю, но думаю, что нет. Потому что:
* зачем шифровать то, что планировалось передавать открытым текстом?
* Opera Turbo на десктопе не шифруется, чтобы все желающие могли посмотреть, чем мы обмениваемся с сервером
Аргументов «за» шифрацию придумать не могу.
Хорошо зашифрованные данные плохо сжимаются. Поэтому единственный вариант был бы «вскрывать» шифрованное соединение и устраивать MitM-атаку на пользователя — а этого мы по соображениям безопасности не хотим.
а щас настраивать панели инструментов низя :-р Нет опций — нет проблем! :-(
а если серьезно, то под Win раньше все рисовалось с помощью WinAPI везде, где можно, а где нельзя — свои решения (например, в адресной строке). Сейчас перешли на Aura — блинковский движок для рисования интерфейса браузера. Под Lin используется та же Aura, что и под Win. Под Mac — пока все делается с помощью «родных» инструментов (тут я в терминологии плохо разбираюсь, но в голове вертится слово Cocoa), но тоже есть мысли о переходе на Aura.
для рисования интерфейса использовались API-вызовы движка. Например, чтобы вывести текст (в главном меню) использовалась команда вывода текста из движка Presto. Если в Blink'е она называется по-другому или имеет другой порядок аргументов — все соответствующие части надо будет переписывать.
Желтый контур, который появлялся вокруг панели инструментов в процессе ее настроек, рисовался средствами CSS-движка. Соответственно, если в Blink'е такой функции нет, то…
Может быть, следовало сделать браузер с двумя движками: один для страниц, второй для интерфейса? :-)
да, в случае если юзерагент определяется на сервере, у нас есть «более тяжелая артиллерия» для подмены юзерагента и в запросах, идущих к серверу, тоже.
Для «забывчивых» разработчиков у нас еще есть команда, в задачи которой входит разговаривать с ними и рассказывать про различие Опер. Вадим как раз в нее тоже входит.
Кто победит в случае «открытой войны» браузера с вебсайтом — не знаю. Точно знаю, что пострадают пользователи.
мы сменим юзерагета на любой другой лично для этого сайта либо перепишем на нем скрипт для определения юзерагета с помощью browser.js. Пока что прецеденты были только из-за невнимательности веб-разработчиков, не знающих, что Опера перешла на новый движок, плюс бюрократии, мешающей им по-быстрому это исправить.
В Opera 12 и ниже уязвимость исправлена отключением SSLv3.
Длинная статья на англ: blogs.opera.com/security/2014/10/security-changes-opera-25-poodle-attacks/
Например, он всегда скачивает последнюю версию, и после скачивания автоматически запускает установщик. А в случае обрыва соединения он может перезапустить закачку.
.app — это, вроде бы, папки, разве нет? А «файлы» — это *.dmg
перезагружать Finder не знаю, зачем, но, может быть, чтобы иконки обновить.
if( navigator.userAgent.match('Opera') ){ код для Presto}
А теперь (когда веб-дизайнер узнал, что у нас в строке User-Agent теперь стоит OPR вместо Opera) стало:
if( navigator.userAgent.match('Opera') || navigator.userAgent.match('OPR') ){ код для Presto}
…
Или «белые списки» user-agent'ов, в которые Оперу забывают включить.
Или считают, что если в строке user-agent упомянут Хром — это значит, что в браузере есть поддержка mp3, H264, PPAPI, NaCl, и т.п. (пользователи Хромиума от этого тоже страдают, да)
ок, похоже, проблема в том, что в бете не скачивается файл browser.js. Спасибо, посмотрю, что можно сделать!
* зачем шифровать то, что планировалось передавать открытым текстом?
* Opera Turbo на десктопе не шифруется, чтобы все желающие могли посмотреть, чем мы обмениваемся с сервером
Аргументов «за» шифрацию придумать не могу.
а если серьезно, то под Win раньше все рисовалось с помощью WinAPI везде, где можно, а где нельзя — свои решения (например, в адресной строке). Сейчас перешли на Aura — блинковский движок для рисования интерфейса браузера. Под Lin используется та же Aura, что и под Win. Под Mac — пока все делается с помощью «родных» инструментов (тут я в терминологии плохо разбираюсь, но в голове вертится слово Cocoa), но тоже есть мысли о переходе на Aura.
Желтый контур, который появлялся вокруг панели инструментов в процессе ее настроек, рисовался средствами CSS-движка. Соответственно, если в Blink'е такой функции нет, то…
Может быть, следовало сделать браузер с двумя движками: один для страниц, второй для интерфейса? :-)
Для «забывчивых» разработчиков у нас еще есть команда, в задачи которой входит разговаривать с ними и рассказывать про различие Опер. Вадим как раз в нее тоже входит.
Кто победит в случае «открытой войны» браузера с вебсайтом — не знаю. Точно знаю, что пострадают пользователи.