Comments 151
Никакой клиентоориентированности
используйте расширения
Это прямо мантра какая-то. Если бы эти расширения ещё умели то, чего от них хотят. Скажем я так и не нашёл ни одного способа сделать жесты как в Opera или Vivaldi в Chrome. А всё дело в различной работе onContext в *nix и windows. У JS-расширений довольно мало полномочий. Или вот пользователи постоянно жалуются на отсутствие вертикальных табов. Но вменяемого API для этого нет.
А вот под nix-ми никак. Предлагаются костыли вроде двойного клика правой кнопкой для вызова меню. Пытаясь решить проблему написал крохотное расширение себе сам. Столкнулся с теми же проблемами, что и остальные: для отмены контекстного меню необходимо блокировать его из oncontext. Но оный в *nix-ах вызывается слишком рано, чтобы можно было отследить какой-нибудь сдвиг мышью.
Именно про неё я и написал выше. Это двойной клик правой кнопкой для контекстного меню. Сам я пошёл немного другим путём: правый клик по ссылке = меню, правый клик по картинке = меню, правык клик по другим местам = жест, правый клик с мод. клавишей = меню. Можно ещё как-нибудь извратиться. А суть остаётся одна — это неудобные костыли.
И кстати говоря, выискивая решения я нашёл инфу о том, что оба автора этих расширений промышляют зловредами. Проверять не стал. Плюс одному из авторов (Smooth Gestures Plus) я дважды писал, что его питон скрипты, которые должны как-то вульгарно обходить проблему, попросту не можут подцепиться к браузеру, судя по логам. Оба раза ответа не получил. Решил больше не связываться вовсе, всё равно то, как это сделали они, я смог за пару часов сам написать. Этого мало :) Хочется удобства, чтобы как под Windows.
Не понял вас. Вот я отловил oncontext. В этом же контексте я должен либо разрешить открытие контекстного меню, либо запретить. Я могу поставить 200ms timeout, но по его окончанию у меня уже нет никакой возможности повлиять на contextMenu. Если я его запретил — то открыть программно нельзя. Если разрешил — то скрыть тоже. Приехали :) Если же организовать в этом контексте синхронный блок на 100+ms, то координаты я всё равно получить не смогу, т.к. JS синхронен.
JS не синхронен классически, но да, он выполняется в один поток (насколько я помню).
Так что тут вопрос скорее к тому, что координаты мышки в функции — это переданные по значению параметры, или это данные, получаемые по ссылке? В первом случае — да, никакой таймаут не поможет, а вот во втором — можно пободаться.
Alt+Left?
Для меня выходом оказался Pentadactyl (vim-like кейбиндинги в браузере (фаерфоксе, правда)).
И бекспейс не нужен, кроме как для текста, и навигация более чем удобно, и мыль-стрелки не нужны.
А что в хроме нет настроек горячих клавишь, как в Вивальди, например?
после того как я первый раз запустил сетап хрома и он не задал ни одного вопроса!, а сразу поставился и иконки свои распихал по всем углам в духе adware, я все понял про этот браузер и больше его на своем компе не видел.
Backspacium… Звучит?
А это будет работать на всех страницах? А до загрузки жабоскрипта? А если вокус не на документе?
Со всеми этими "расширениями" одна проблема — они хуже встроенного решения.
Плагиновые мышиные жесты после встроенных в Опере выглядят как грязный глючный костыль: в окнах настроек не работает, рисовать можно только внутри документа, при вылетании мыши за границу рисование залипает, флипы творят чудеса с выделением… глюк на глюке. Сверху вон пишут, что оно ещё и не под всеми осями работает.
В общем, не будем про *опу и руки.
Так что, думаю, Firefox более продуман в этом плане, и кнопку не отключили, и удобства добавили (мало ли еще какие казусы с навигацией у пользователя). Не в ту сторону Chrome смотрит, не в ту.
я вот только сейчас задумался над тем что уже много много лет все переходы осуществляю открывая ссылки в новом табе. и «назад» превратилось в комбинацию ctrl+w
Тем более в данном случае, когда опцию можно засунуть в about:config и осчастливить всех пользователей.
1. Для копирования и вставки используют не Ctrl+C, Ctrl+X, Ctrl+V, а Ctrl+Ins, Shift+Del и Shift+Ins.
2. Для переходов между страницами не Backspace, а Alt+Left, Alt+Right, они же настроены на боковые кнопки мыши.
3. Вместо Ctrl+Alt+Del — Ctrl+Shift+Esc.
Когда полноэкранное приложение зависло и "не отдает" экран — только Ctrl+Alt+Del спасает. Ctrl+Shift+Esc приводит к запуску диспетчера задач в фоне, без возможности на него переключиться.
Зависает полноэкранная игра, жмешь Ctrl+Alt+Del и появляется панель задач. При этом на запущенные приложения можно навестись мышью и увидеть, что они исправно работают в фоне. Вот только переключиться туда никак.
Ну и в диспетчере задач не надо убирать «Поверх всех окон» или ставить сторонний (Process Explorer у меня).
— ctrl+alt+del, Task Manager. Игра покрывает всё чёрным фоном.
— курсор вниз, возможно ещё раз ctrl+alt+del, появляется панель задач
— не кликая, навести курсор на кнопку диспетчера. Появляется превью окна
— перевести курсор на превью и кликнуть
— игра опять всё закрывает, повторить магию появления панели задач, опять навести курсор на превью, не кликая, стрелками выбрать процесс и нажать del
2. ctrl-w всемогущий! :) Нет, правда, нажать кнопку назад мне приходится раз 5 за неделю — от силы.
3. согласен с предыдущими ораторами — Ctrl-Alt-Del в большинстве случаев неюзабельно, давно переключился на ctrl-shift-escape.
В windows 10 уже работает)
А на ноутах или вырвиглазных клавах этот Ins быаает с ходу и не найдешь. Да и может одной руки и не хватить что бы от контрола дотянуться.
С трудом представляю, что может быть удобнее. Если конечно страничка не предполагает активного использования клавиатуры, тогда Alt+Left можно нажать быстрее, чем до мыши тянуться.
Всегда бился ею о клавиатуру и браузер, зараза, шёл назад. После чего я бился уже в истерике.
Сейчас проблема решена, на мышке просто нет этих кнопок :)
А вообще про навигацию и хоткеи вопрос спорный.
Я так и не привык пользоваться Ctrl+x,c,v — так с 90-х и пользую Ctrl+Ins, Shift+Ins. И везде, где этого нет, но можно настроить, делаю так.
И в браузере по-моему BackSpace идеальный вариант. Жаль, что убирают.
Но с другой стороны, учитывая, что ни один браузер страницы, с которых ушли, не открывает мгновенно, смысла в переходе обратно нету, и открытие всех ссылок в новой вкладке в корне избавляет от необходимости их открывать и ждать.
При движении мыши влево, если стукнуться большим пальцем о ноутбук или «взрослую» клаву, то именно этот палец на кнопку и нажимает.
Я эти кнопки всегда как мог отключал.
Где-то программно, где-то микропереключатель перепаивал на место уже раздолбанного основного.
Но подумав, ка бы я их мог использовать, прихожу к другому вопросу.
А как вы нажимаете эти кнопки? Ведь при этом мышка норовит уехать в сторону. И для того, чтобы нажать нужно либо мышь сильно придавить, либо с другой стороны пропорционально усилию тоже придерживать. Но там — другая кнопка… И нажимаются две…
А насчет кнопок — ни разу за все годы использования не было проблем с лишним перемещением мыши от нажатия. Да и ухватить её так, чтоб одновременно оказались прижаты кнопки с обеих сторон тоже не смог. Разве что скрючив пальцы в непонятную композицию достал с обеих сторон, но и тогда при нажатии никаких поползновений к нажатию с правой стороны.
Ну и насчет случайного срабатывания, палец не лежит постоянно на кнопке, а в выемке чуть ниже нее. Поэтому как не двигай мышь, максимум пальцем упрешься в клавиатуру. Но даже так задеть её получается очень редко. Разве что выкрутить чувствительность совсем на минимум и размахивать ею на 20 см…
теряя [введённые в формах] данные
Т.е. вместо того, чтоб сделать сохранение введённых данных на странице, мы удаляем кнопку. Нету кнопки — нет проблем.
В Опере с таким встречался, но очень редко (на хабре сейчас почему-то всё время обновляет страницу, а раньше из кэша брал вместе с комментарием).
Т.е. вместо того, чтоб сделать сохранение введённых данных на странице, мы удаляем кнопку. Нету кнопки — нет проблем.
Я вас разочарую. Восстановление сохранённых введённых на странице данных далеко не всегда возможно. Во всяких сложных динамических по самое не могу SPA, это будет работать, только если сами разработчики озаботятся такой функциональностью. Да и без сложного JS такое поведение, может что-нибудь поломать в уже сущ-их сайтах.
Ваше право, кто ж это оспаривает. Но, вопреки вашим желаниям, интернет всё больше и больше становится площадкой для вебсайтов-вебприложений (таких как gmail или почти все соц. сети), нежели набором страниц с небольшим кол-вом форм. Очень многие вещи, которые раньше были мыслимы только как desktop приложения переехали в web. Не желаете их использовать? Ok.
Другое дело, что это может быть очень затратно по памяти: существуются сайты, страницы которых занимают почти 100 мбайт памяти браузера, например, блоги, на каждый из комментариев навешана тонна функционала.
Технически просто замораживать страницу и прятать вкладку.
Вот эта страница у меня сейчас кушает 69 MiB. А скажем gmail кушает 311 MiB. Куда их сгружать? На диск? С какой скоростью нынче работают HDD? Вы готовы терпеть много-секундные тормоза при любой смене URL? Снапшот страницы современного web-приложения может быть ну очень весомым. Не смотря на довольно быструю работу.
Суть в том, что раньше web был довольно простым и можно было прибегнуть к ряду уловок. К примеру я лично восстанавливал из кеша браузера страницу с расписанием экзаменов в opera10, которую закрыл 2 недели назад. Но сейчас подобные вещи стали слишком расточительными.
Правильнее воспринимать веб-сайты как, скажем, приложения на android или ios, которые не требуется предварительно устанавливать. Аналогия не совсем верна (эти приложения порой больше 30 MiB непонятно на что кушают), но общую суть отражает.
9 мегов хранить проблем обычно не вызывает, тем более, что хранить нужно упакованный DOM, можно даже без картинок.
А gmail — это уже полноценное веб-приложение, использующее History API, поэтому там проблема с сохранением данных при нажатии на Back/Forward не особо актуальна.
В процессе эволюции веб в сторону веб-приложений плохо будет тем пользователям, которые привыкли использовать множество вкладок.
Что-то многовато будет.
Что есть, то есть :) То были числа от Chrome. А вот Vivaldi так вообще объединил 3 таба в 1 процесс (фигасе), но он и ест за 3-х: 410 MiB.
Правда у меня 64bit Linux, и 16 GiB ОЗУ. Так что он может быть столько кушает потому, что есть что кушать. Посмотреть можно нажав shift+esc.
Наиболее эффективным по потреблению памяти оказалось агрессивное использование NoScript (разрешать только скрипты, без которых полноценная работа с сайтом невозможна). Одно его использование уменьшает потребление главной geektimes с 15М до 6M. Добавление ABP — ещё до 4.3M, Ghostery — увеличивает до 4.6M, но зато эффективно работает на развлекательных сайтах.
С uBlock получилось похуже, видимо из-за того, что я им не пользуюсь и не добавляю свои фильтры — с ним проскавает реклама. Использование вместе ABP + uBlock сильно неэффективна из-за повышения накладных расходов, достаточно чего-то одного.
Я веб-разработчик. И не использую даже блокировщика рекламы. В первую очередь по морально-этическим обстоятельствам. Во-вторую, потому что знаю, что подобные модификации DOM-а, незапланированные разработчиком, могут что-нибудь сломать на странице, а это последнее чего я жду. А экономить память смысла не вижу, если честно. У меня её очень много (специально взял 16 GiB, чтобы не испытывать ни проблем с производительностью, ни с кол-ом памяти). А от NoScript у меня начинает глаз дёргаться. Дальше только Lynx :) Попробуйте его, уверяю, потребление памяти будет смехотворным :D
Я веб-разработчик.… А экономить память смысла не вижу, если честно. У меня её очень много (специально взял 16 GiB, чтобы не испытывать ни проблем с производительностью, ни с кол-ом памяти).
Вот так всегда. Разработчики делают свои творения с 16 Гб памяти, и даже не понимают почему пользователи недовольны...
Прошу не путать: я то исхожу с точки зрения потребителя, т.е. пользователя. И я знаю, что с резервом ОЗУ, при современных обстоятельствах, мне будет комфортно. ОЗУ дешёвые. Более того, я купил SSD, зная что это того стоит.
А вот логика из которой исходят разработчики браузеров совсем иная. Они ведь не могут заставить пользователей покупать планки ОЗУ, SSD диски и пр… Но я полагаю всё дело в повышенном требовании к быстродействию, которое достигается за счёт прожорливых к ОЗУ оптимизаций. Насколько это правильно или нет, судить не мне.
1. В отличие от большинства пользователей, вы, видимо, используете компьютер исключительно для работы, не заходите на развлекательные сайты, не пользуетесь торрентами.
2. Вы считаете рядового пользователя слишком продвинутым. Это не так. Рядовой пользователь не побежит в магазин покупать память или SSD, если увидит, что «интернет тормозит». Он будет просто страдать.
3. Большое количество памяти не означает, что её нужно использовать всю. Хотя бы потому, что свободная память нужна для эффективной работы дискового кэша. Мне, кстати, и 16 гигов мало (больше, к сожалению, не воткнуть без полного апгрейда) — даже несколько раз своп приходилось включать. Ещё не хватало, чтобы браузер лишний гиг ел.
Прожорливые оптимизации, если и есть, то касаются выполнения JS. И именно на исполнение JS кода и уходит львиная доля памяти браузера. Медиаконтент находится только на втором месте, DOM — на третьем.
Именно поэтому я и не люблю скрипты. Если есть возможность обойтись без них — лучше обойтись без них. И да, я очень вредный. Морально-этические принципы меня не волнуют: зачем терпеть то, что сильно мешает? Я асоциален, и вырезаю с сайтов даже кнопки соцсетей. Просто мне так удобно.
- Нет — посещаю, нет — использую.
- Нет не считаю. С чего вдруг? И вообще причём тут рядовые пользователи?
- А я тут причём? Я что-ли браузеры пишу?
@DistortNeo, очень прошу, если критикуете что-то, то хотя бы не по диагонали читайте. Брр… О чём я написал? О том, что ОЗУ потребляют браузеры нынче много. О том, что можно улучшить эту ситуацию, будучи пользователем сети, если смириться с этим и докупить планку ОЗУ. А вы меня в чём обвиняете? Я что-ли браузеры пишу? Или у вас есть основания полагать, что я пишу веб-приложения, которые рассчитаны на большое кол-во ОЗУ? Я просто обрисовал вам ситуацию такой, какова она есть.
… … … Просто мне так удобно.
Благодарите web-технологии за то, что в них всё это возможно. В desktop-приложениях у вас не было бы такой роскоши ;)
Во-первых (уровень безопасности): интернет для массового пользователя. Массовому пользователю хочется чтобы было красиво и функционально. Отсюда растут ноги у всяческих js обвязок, скриптов и веб-приложений. А они, как вы уже заметили — любят хорошо кушать память. Иначе тормозить будут. Как этого можно избежать? Избежать этого можно только с помощью более низкого и опасного уровня выполнения (jvm/прочие машины-исполнители байт-кода). Именно так появился в своё время Flash и java-апплеты. С тех пор производительность машин стала достаточной, чтобы тянуть это всё в более безопасном (изолированном) контейнере.
Во-вторых (стоимость разработки): стоимость разработки намного превышает стоимость оперативной памяти. Слишком требовательный пользователь или докупит памяти или закроет какие-нибудь другие вкладки, чтобы поработать с этой. Это работает. Возможно не для всех, но компании не будут тратить из-за малого количества страдающих свои средства на улучшение ситуации.
В-третьих (функционал): чем лучше функционал либо чем красивее он подаётся (зависит от ЦА), тем больше шансов получить с клиентов деньги. А это однозначно повышает сложность и цену разработки и поддержки веб-систем.
И нет никакого заговора. И да, разработчик бы и рад бы порой пооптимизировать, но в плане для этого нет времени (клиент не выделил под это денег и/или есть куча других намного более приоритетных задач).
Честно говоря, всякий раз, когда я сталкивался с тяжело-загруженными веб-приложениями (мой род деятельности и с ними связан — закрытые толстые АРМ системы), то Firefox показывал сильно худшую производительность. Так что тут палка о двух концах. Я бы не сказал, что Firefox решил вопрос. Скорее ребята из Mozilla могут придерживаться другого подхода.
Оптимизациями "под браузер", как правило, никто не занимается. В том числе и я. Учитывая скорость их развития и сложность устройства под капотом, это мало-перспективная деятельность. Скажем есть вот такое вот. На этом можно что-нибудь выиграть. Но вероятность встретить подобные уловки в реальном коде стремится к нулю.
Т.е. если кратко: нет, ни маленькие, ни большие продукты на JavaScript-е практически никто не пишет под браузеры. В том числе и я. К тому же сам JS это динамически типизированный язык, что слабо располагает хоть к каким-нибудь хакам производительности. А на тех же C++ люди порой даже ASM вставки делают.
Так что нет. По "остаточному принципу" идёт оптимизация как таковая, а не под chrome.
У меня вот не получается игнорировать окружение — при разработке в хроме бывают проблеме в FF, при разработке в FF — бывают серьёзные проблемы в хроме.
Так что же тогда можно сказать о производительности, если даже функционирование фич приходится в каждому требуемом брауезере проверять? А производительность (в отличие от неработоспособности) чаще всего не является достаточной причиной, чтобы выделять дополнительное.
Хм… т.е. вы считаете, что если основное окружение, под которое идёт разработка не влияет на разработку? Мне кажется вы «немного» лукавите
А вот как раз этого я и не говорил ;) Если разработчик использует для разработки Chrome, то у него изредка будут проявляться неизвестные ему баги в Firefox. Со мной такое иногда случается. Т.к. даже интерпретация JS-кода по мелочам да различается (к примеру for-of
). Ну и наоборот.
Но вот применить ту же логику к оптимизации получается слабо. Т.к. язык интерпретируемый и оптимизацией JS кода в целом практически никто и не занимается. Не те задачи, не те сроки, не те условия.
Почему V8 работает так быстро? Я думаю ответ прост: в него влили так много бабла и труда, что даже такой язык как JavaScript с его слабой дин. типизацией — смог залетать. Вот.
Но! Касательно производительности и оптимизации: пишут под интерпретируемый язык и поэтому, да, об оптимизации JS-кода обычно особо то и не задумываются.
при заполнении веб-форм с текстом процент навигации на предыдущую страницу с помощью Backspace падает до ничтожных 0,005%. Очевидно, люди боятся потерять введённые данные. Если текстовая форма не в фокусе, то нажатие Backspace не удалит предыдущий символ, а загрузит предыдущую страницу с потерей данных, введённых в форму.
Что за бред? Они не рассматривали вариант, что процент падает т.к. курсор стоит в одном из полей и что-то удаляет вместо того, чтобы осуществить навигацию?
Вот и наказание мне за то, что галочка "отправлять гуглу статистику" не поставлена… На ноутах давно жестом назад хожу, но backspace — всё-таки хоткей для "назад" с начала времён, и я им пользовался.
давно сделал так потому что испытывал те же проблемы что и в статье
Chrome отключил навигацию назад по кнопке Backspace