Гм, у меня в Chrome вот так бывает. Но вполне вероятно, что я когда-то поменял настройку "Always use secure connections", не помню, что там было по умолчанию. Однако настройка такая есть.
в случаях когда там что-то не так — есть как раз я )
Кстати, раз уж пошла такая жара, еще два момента.
У меня что-то фризится секунд на 10 последние пару дней вкладка с Хабром, когда я открываю пост о Firefox, чтобы почитать свежие комментарии. Как-то странно для последнего MBP на M1 Pro. Открыл пару других постов с большим количеством комментариев, вроде такого нет, но там у меня не 100 непрочитанных комментариев.
Относительно непрочитанных комментариев как раз. Я какое-то время назад (а точнее уже почти полгода, 11 августа) обращался с проблемой перехода между непрочитанными комментариями. Кейс: открыл статью из непрочитанными комментариями, промотал к интересующей ветке (какие-то непрочитанные комментарии остались вверху) и хочешь дальше переходить между комментариями стрелками возле каунтера непрочитанных (или клавишами k и j). На старой версии переход начинался с первого непрочитанного комментария, видимого на экране или ниже. Новая версия прыгает вверх аж к первому комментарию, который ты специально промотал. Прямо очень раздражает. Может, конечно, вы так и хотите, чтобы работало, но это не очень удобно.
Да на самом деле уже не все так плохо. Я пару раз попрыгал между старой и новой, понял, что привыкать рано или поздно все равно придется. Решил начать привыкать пораньше 🙂
Если только читать, то уже жить можно. Писать сложнее, но текст почти нормально переносится из Notion, где я последнее время пишу, так что тоже терпимо.
Всегда указываю в багрепортах версии ПО и проч. нужную информацию.
Да я обычно тоже, но при обращении через форму на сайте относительно ошибки на этом самом сайте, то ожидаешь, что эта информация и так должна собраться. Даже при отправке формы там есть ссылка на Privacy Policy, где упоминается сбор:
browser data (type, version, cookie);
operating system data (type, version, screen resolution);
query data (time, source, IP address).
other impersonal information about User’s activity in the Application.
приходится как сайгак между версиями переключаться, чтобы понять в какой сидит юзер
Кстати, насчет этого, я ведь обращался через форму на сайте. У вас не собирается при отправке какая-то общая информация? Хотя бы ОС, браузер и версия Хабра.
Оператор службы поддержки работал в другом окружении и у него это не воспроизвелось (как и у некоторых в комментариях тут)
Не воспроизвелось только у тех, кто на старой версии сидит. У вас даже поддержка старую версию предпочитает? Это прямо звоночек 😀 И судя из комментария, я не первый в поддержке с таким вопросом.
в будущем о подобных историях можно писать мне напрямую
Ок, но хотелось бы, конечно, чтобы так делать не приходилось. Думаю, некоторое количество пользователей Хабра могут и не знать, кто такой @Boomburum 🙂
прорвавшись через первую линию техподдержки, что весьма непросто, потому что там любой юзер изначально считается идиотом по умолчанию (и это много где так)
Вот с этим как раз главная беда, потому что на Хабре (из моего опыта во всяком случае) никогда так не было. Что логично, потому что тут средний юзер не равен среднему юзеру какого-нибудь Авито (не в обиду пользователям Авито сказано).
Нет, не починили, но, видимо, сломано только на macOS. Cmd + Click все так же не работает, а Ctrl + Click на Маке и не работал никогда. На винде через Parallels Ctrl + Click тоже не работает.
Проблемы разного уровня. Если после одного запроса пропадает сеть и 2 других не доходят, незаконченная сущность будет болтаться на бекенде неопределенное количество времени. Мне что-то кажется, вы не делали мобильных приложений :)
авторизация на сервере авторизации, получение справочников из cdn и создание профиля на конкретном сервисе
Это три разные вещи, непонятно, почему мы о них говорим.
Чего это для одинарного запроса вам разная обработка не нужна, а для тройного вдруг потребовалась?
Ну, представим ситуацию. Она почти выдуманная (похожее в моей практике было). В мобильном приложении пользователь создает каким-то образом сущности "магазин", "отдел", "полка", которые, конечно же, связаны между собой. Упертый бекенд хочет строго следовать json api и требует отправлять эти сущности тремя разными post-запросами. Как я писал выше, потому что бекенду "так удобнее". Каждый запрос отправляет свои поля, поэтому ошибки валидации могут быть разные.
Также надо решать вопрос, что один запрос успешен, а 2 зафейлились. Либо это на клиенте трекать, и отсылать только зафейлившиеся запросы, что добавляет оверхеда в логике клиента. Либо делать ретрай всех полей сразу, что привносит оверхед на использование трафика пользователя, возникает больше точек соприкосновения с идемпотентностью бекенда.
ещё 3 запроса можно запускать параллельно да ещё и к разным серверам и по разному кешировать
Если надо 3 запроса к 3 разным серверам, то это будет 3 запроса. Но мы сейчас говорим немножко не об этом. И опять же если у нас клиент ходит в 3 разных места, то чаще всего мы что-то делаем не так. Логику похода в разные места на бекенд закинуть опять же проще, а не раскрывать такие знания клиенту.
Заем вы обрабатываете ошибки каждого запроса по отдельности?
За тем, что для разных ошибок требуется разная обработка, в зависимости от контекста.
И тут дело не только в обобщенном коде. 3 запроса с клиента — это менее стабильно, сеть может пропасть между запросами, надо решать вопросы, например, консистенции из-за этого.
лучше бы фронты не брались действительно за проектирование апи, если у них нет знания кодовой базы бека и бд. Ну либо апи разрабатывалось бы совместно
Право на жизнь имеет скорее только совместное проектирование. Бекендеры ведь тоже не какие-то небожители. На своей практике миллион раз встречался с ситуацией, когда бекенд сделан невероятно топорно для использования с фронта, потому что "так было удобнее". А то, что вместо одного запроса надо отправить три 3, соответсвенно, ошибки каждого требуется обработать и как-то вплести во флоу пользователя — это пустяки.
В целом бекенд должен быть готов на большее количество уступок. Потому что задеплоить какое-то изменение или фикс на бекенд намного быстрее, чем на клиент, если клиентов несколько либо это не веб-фронтенд.
Ну да, но речь же о клике колесиком, а не ПКМ.
Гм, у меня в Chrome вот так бывает. Но вполне вероятно, что я когда-то поменял настройку "Always use secure connections", не помню, что там было по умолчанию. Однако настройка такая есть.
А это еще не так?
На маке такого нет, увы 🙂 тут вообще левой и правой кнопок на трекпаде нет — только нажатие одним пальцем или двумя.
Кстати, раз уж пошла такая жара, еще два момента.
У меня что-то фризится секунд на 10 последние пару дней вкладка с Хабром, когда я открываю пост о Firefox, чтобы почитать свежие комментарии. Как-то странно для последнего MBP на M1 Pro. Открыл пару других постов с большим количеством комментариев, вроде такого нет, но там у меня не 100 непрочитанных комментариев.
Относительно непрочитанных комментариев как раз. Я какое-то время назад (а точнее уже почти полгода, 11 августа) обращался с проблемой перехода между непрочитанными комментариями. Кейс: открыл статью из непрочитанными комментариями, промотал к интересующей ветке (какие-то непрочитанные комментарии остались вверху) и хочешь дальше переходить между комментариями стрелками возле каунтера непрочитанных (или клавишами k и j). На старой версии переход начинался с первого непрочитанного комментария, видимого на экране или ниже. Новая версия прыгает вверх аж к первому комментарию, который ты специально промотал. Прямо очень раздражает. Может, конечно, вы так и хотите, чтобы работало, но это не очень удобно.
Да на самом деле уже не все так плохо. Я пару раз попрыгал между старой и новой, понял, что привыкать рано или поздно все равно придется. Решил начать привыкать пораньше 🙂
Если только читать, то уже жить можно. Писать сложнее, но текст почти нормально переносится из Notion, где я последнее время пишу, так что тоже терпимо.
Да я обычно тоже, но при обращении через форму на сайте относительно ошибки на этом самом сайте, то ожидаешь, что эта информация и так должна собраться. Даже при отправке формы там есть ссылка на Privacy Policy, где упоминается сбор:
browser data (type, version, cookie);
operating system data (type, version, screen resolution);
query data (time, source, IP address).
other impersonal information about User’s activity in the Application.
Кстати, насчет этого, я ведь обращался через форму на сайте. У вас не собирается при отправке какая-то общая информация? Хотя бы ОС, браузер и версия Хабра.
увы, я всю жизнь на ноутах, где нет колесика, поэтому привычка строго противоположная
Отлично, спасибо, буду знать.
Не воспроизвелось только у тех, кто на старой версии сидит. У вас даже поддержка старую версию предпочитает? Это прямо звоночек 😀 И судя из комментария, я не первый в поддержке с таким вопросом.
Ок, но хотелось бы, конечно, чтобы так делать не приходилось. Думаю, некоторое количество пользователей Хабра могут и не знать, кто такой @Boomburum 🙂
Да, все примерно так и есть.
Вот с этим как раз главная беда, потому что на Хабре (из моего опыта во всяком случае) никогда так не было. Что логично, потому что тут средний юзер не равен среднему юзеру какого-нибудь Авито (не в обиду пользователям Авито сказано).
В футере у вас есть такое? Значит, новая.
Ну, проверил через Parallels в Edge — Ctrl + Click ведет себя все так же некорректно. У вас точно новая версия Хабра?
Нет, не починили,
но, видимо, сломано только на macOS. Cmd + Click все так же не работает, а Ctrl + Click на Маке и не работал никогда.На винде через Parallels Ctrl + Click тоже не работает.Нотариально заверенный скриншот © подойдет? :)
Проблемы разного уровня. Если после одного запроса пропадает сеть и 2 других не доходят, незаконченная сущность будет болтаться на бекенде неопределенное количество времени. Мне что-то кажется, вы не делали мобильных приложений :)
Это три разные вещи, непонятно, почему мы о них говорим.
Ну, представим ситуацию. Она почти выдуманная (похожее в моей практике было). В мобильном приложении пользователь создает каким-то образом сущности "магазин", "отдел", "полка", которые, конечно же, связаны между собой. Упертый бекенд хочет строго следовать json api и требует отправлять эти сущности тремя разными post-запросами. Как я писал выше, потому что бекенду "так удобнее". Каждый запрос отправляет свои поля, поэтому ошибки валидации могут быть разные.
Также надо решать вопрос, что один запрос успешен, а 2 зафейлились. Либо это на клиенте трекать, и отсылать только зафейлившиеся запросы, что добавляет оверхеда в логике клиента. Либо делать ретрай всех полей сразу, что привносит оверхед на использование трафика пользователя, возникает больше точек соприкосновения с идемпотентностью бекенда.
Если надо 3 запроса к 3 разным серверам, то это будет 3 запроса. Но мы сейчас говорим немножко не об этом. И опять же если у нас клиент ходит в 3 разных места, то чаще всего мы что-то делаем не так. Логику похода в разные места на бекенд закинуть опять же проще, а не раскрывать такие знания клиенту.
За тем, что для разных ошибок требуется разная обработка, в зависимости от контекста.
И тут дело не только в обобщенном коде. 3 запроса с клиента — это менее стабильно, сеть может пропасть между запросами, надо решать вопросы, например, консистенции из-за этого.
Право на жизнь имеет скорее только совместное проектирование. Бекендеры ведь тоже не какие-то небожители. На своей практике миллион раз встречался с ситуацией, когда бекенд сделан невероятно топорно для использования с фронта, потому что "так было удобнее". А то, что вместо одного запроса надо отправить три 3, соответсвенно, ошибки каждого требуется обработать и как-то вплести во флоу пользователя — это пустяки.
В целом бекенд должен быть готов на большее количество уступок. Потому что задеплоить какое-то изменение или фикс на бекенд намного быстрее, чем на клиент, если клиентов несколько либо это не веб-фронтенд.
а почему, можно поинтересоваться?