Контакт прыгает не из-за Оперы — это там, наоборот, вКонтакте стоит костыль, исправляющий что-то из багов 10й версии, который «подёргивает» страницу.
function(real_blur) {
if (browser.opera && !real_blur) {
setTimeout(function() { activity_editor.blur(1); }, 100);
return false;

Оставлю это здесь
habrahabr.ru/blogs/opera/85860/

такая же штука с плашкой, когда full-screen игры сворачиваю. Ещё у меня во флэше у букв белые границы повсеместно, что нехило ухудшает читаемость.

в Джумле та же песня — стабильный краш…

Какого вида сохранение?
Мне, кажется, хватало просто «Файл»->«Сохранить страницу».
Впрочем, не пользовался этим уже года два-три, могу и врать, проверьте кто-нибудь.

Закройте топик для подписчиков блога — будет меньше троллинга.

Попробуйте открыть глаза, возопив гневным комментом в блоге разработчиков (по той ссылке, что у вас в конце сообщения) с указанием номеров багов. Там выше вероятность, что прислушаются, имхо.

а дальше куда? Видимо я плохо искал…

у меня тоже не вешает, но вот проблемы с крашем при заходе на blogspot огорчают (…

В случайное время. Опера работает практически круглосуточно, иногда перезагружаю ее.

Этот баг «не прозрачный», т.е. через эту полоску нельзя выбрать вкладку, если только над ней.

Как появится вновь, сделаю скриншот.

Замечал 3 раза.

XP SP3. Слева по кнопке меню попадает, справа по крестику нет.

Передёргивание выглядит как на ВК — такое ощущение, что css отключается на доли секунд. В b2 у меня тоже всё нормально было.

В этом билде оно у меня ещё и принудительно закрываться перестало.

У Оперы на сайте какой-то странный и недружественный механизм приёма багов от пользователей.
По логике правильно было бы:
1. В доступном месте сайта оставить ссылку на багтрекер.
2. В багтрекере дать удобный механизм для просмотра, поиска и сортировки уже зарегистрированных багов.
3. Перед окончательной регистрацией нового бага находить по ключевым словам в базе уже зарегистрированные похожие баги и показывать их пользователю (чтобы избежать дублирования).
4. После регистрации сообщать пользователю, что его баг-репорт зарегистрирован на трекере с таким-то номером.
5. Юзеру на почту сразу же дублировать информацию о номере зарегистрированного бага вместе с его описанием и дать ссылку для отслеживания его состояния, рассмотрения, обсуждения и решения.
6. При изменении статуса (выполнение/отклонение) высылать пользователю по почте информацию об этом изменении.

А сейчас нужно кучу кликов сделать, чтобы найти где оставить баг-репорт на сайте. А при регистрации баг-репорта как в чёрную дыру кинул, ни узнать номер, ни посмотреть список багов, ни сделать поиск, ни узнать статус решения — ничего нет!
После такого наплевательского отношения Оперы к пользователям пропадает всякое желание баг-репорты слать.

Согласен с вами. Но все равно огорчает тот факт, что бетами и даже RC не удается пользоваться полноценно, особенно, когда уже привык это делать на предыдущей версии. Будем ждать финального релиза, в нем наверняка пофиксят все нынешние проблемы.

Зачем так торопиться? Выпустили бы какую-нибудь промежуточную версию нерелизную. А так получается сырой продукт, тем более в линуксовой версии в плане багов вообще кошмар.

Замечал такое, при чем часто. Но тут главное вовремя изменить тип на ".avi" (etc), и выбрать тип файла «Все файлы», иначе и сохранит как html, по-моему и файл будет «битым».

На файлообменниках регулярно )
Иногда помогает такой финт ушами, вместо того, чтобы кликнуть левой кнопкой мыши, кликаем правой и выбираем «Save Linked Content As...»

Причина в том, что Opera принципиально в целях безопасности не обрабатывает файлы по расширению, а ждёт от сервера адекватной информации о типе файла. Если никакой инфы нет — файл грузится по умолчанию — как HTML. С лёгкой руки IE пошла практика определения контента по расширению, все остальные ей следуют в той или иной степени. В Opera, повторю, этого нет принципиально.

Баг превращаем в фичу)))

А вот так да, баг «работает» :)

Вообще, похоже, что «Save image» просто висит на LeftMouseButtonUp при условии нажатого Control'a. Без анализа, была ли кнопка нажата на этой же картинке.

Просто когда нужно скопировать строку/фрагмент который выделяешь, и вот тут как раз и попадается это «сохранение изображения».
P.S. когда нужно быстро выделить и скопировать :)

Подозреваю, что просто поломали алгоритм интерполяции масштабированных скриншотов.

Спасибо, теперь всё, как надо!

у меня тоже — и поиск и настройки от 10.10.

Покажите.

пысы: плюсанул, чтобы не думали, что «фанатики злые» :)

Тогда назовите, пожалуйста, хотя бы один продукт (или в данном контексте браузер), в котором не было бы ниодной недоработки.

Нет, этот баг только у Оперы, причем в разных версиях появляется в разных случаях. Не только кстати с яваскриптом, но и с меню, построенных на hover — иногда куски картинки не прорисовываются. Мне приходилось его решать тем, что под меню в ходе анимации двигался невидимый див, который и заставлял Оперу прорисовывать движущиеся части.

Хорошо, пока меня не заплевали, дам вам пруф…

Итак, RFC 2183 — The Content-Disposition Header Field гласит:

Current [RFC 2045] grammar restricts parameter values (and hence Content-Disposition filenames) to US-ASCII. We recognize the great desirability of allowing arbitrary character sets in filenames, but it is beyond the scope of this document to define the necessary mechanisms. We expect that the basic [RFC 1521] `value' specification will someday be amended to allow use of non-US-ASCII characters, at which time the same mechanism should be used in the Content-Disposition filename parameter.

Т.е. «мы понимаем, что это плохо, но в заголовках допустимы только US-ASCII, однако окончательный выбор за базовым для всего MIME — RFC 1521».

Хорошо, смотрим в RFC 1521- TMIME (Multipurpose Internet Mail Extensions) Part One:

The description is presumed to be given in the US-ASCII character set, although the mechanism specified in [RFC-1522] may be used for non-US-ASCII Content-Description values.

Уже лучше — мол «все-таки надо бы в US-ASCII, но вообще-то есть еще один механизм, посмотри-ка его в RFC-1522...».

Смотрим в RFC-1522- RFC1522 — MIME (Multipurpose Internet Mail Extensions) Part Two и… Видим MIME-кодирование заголовков. Да-да, то самое, знакомое любому программисту, который хоть раз отправлял программно письмо с кириллицей в поле Subject. Что неудивительно, ибо все MIME заголовки, будь то Subject или Content-disposition происходят из одного и того же базового RFC, и нигде в них не используется UTF-8, как это предлагает делать опера.

lenta.ru/articles/2010/03/01/browser/
Им надо успеть выпустить финальную версию сегодня, в крайнем случае завтра.

Виноват

DSK-271728 — resolved (invalid)
DSK-271727 — resolved (duplicate), родительский баг ещё не починен, но над ним уже работают.

Был включен. В Network ничего не трогал, починилось релогином в учетную запись.