Поддержка браузера Chrome – Chrome Enterprise

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

Вы также можете найти ответы на вопросы и инструкции по устранению неполадок в нашем Справочном центре.

Поддержка Chrome на всех платформах

Если у вас возникнут вопросы о консоли администратора Google или использовании браузера Chrome в ОС Windows, Mac, Linux и ChromeOS, вы всегда можете обратиться в службу поддержки онлайн или по телефону.

Помощь в управлении правилами

Наши эксперты помогут вам настроить сотни правил и работать с ними с помощью групповых политик Windows или облачного управления браузером Chrome.

Поддержка при настройке устаревших приложений

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

Улучшенная безопасность, расширенное управление

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

Связаться с нами

Заполните эту форму, чтобы больше узнать о получении поддержки Chrome для вашей компании

Значком * отмечены обязательные поля.

Укажите имя.

Имя

Укажите фамилию.

Фамилия

Укажите действительный адрес электронной почты.

Электронная почта

Номер телефона

АвстралияАвстрияАзербайджанАлбанияАлжирАмериканское СамоаАнгильяАнголаАндорраАнтигуа и БарбудаАргентинаАрменияАрубаАфганистанБагамыБангладешБарбадосБахрейнБеларусьБелизБельгияБенинБермудыБолгарияБоливияБонэйр, Синт-Эстатиус и СабаБосния и ГерцеговинаБотсванаБразилияБрунейБуркина-ФасоБурундиБутанВануатуВатиканВеликобританияВенгрияВенесуэлаВиргинские острова (Великобритания)Виргинские острова (США)Восточный ТиморВьетнамГабонГаитиГайанаГамбияГанаГваделупаГватемалаГвинеяГвинея-БисауГерманияГибралтарГондурасГонконгГренадаГренландияГрецияГрузияГуамДанияДемократическая Республика КонгоДжибутиДиего-ГарсияДоминикаДоминиканская РеспубликаЕгипетЗамбияЗимбабвеИзраильИндияИндонезияИорданияИракИранИрландияИсландияИспанияИталияЙеменКабо-ВердеКазахстанКамбоджаКамерунКанадаКатарКенияКипрКиргизияКирибатиКитайКолумбияКоморы и МайоттаКонгоКосовоКоста-РикаКот-д’ИвуарКубаКувейтКюрасаоЛаосЛатвияЛесотоЛиберияЛиванЛивияЛитваЛихтенштейнЛюксембургМаврикийМавританияМадагаскарМакаоМакедонияМалавиМалайзияМалиМальдивыМальтаМароккоМартиникаМаршалловы ОстроваМексикаМикронезияМозамбикМолдавияМонакоМонголияМонтсерратМьянмаНамибияНауруНепалНигерНигерияНидерландыНикарагуаНиуэНовая ЗеландияНовая КаледонияНорвегияОбъединенные Арабские ЭмиратыОманОстров ВознесенияОстров НорфолкОстров Святой ЕленыОстрова КайманОстрова КукаПакистанПалауПалестинаПанамаПапуа – Новая ГвинеяПарагвайПеруПольшаПортугалияПуэрто-РикоРеюньонРоссияРуандаРумынияСШАСальвадорСамоаСан-МариноСан-Томе и ПринсипиСаудовская АравияСвазилендСеверная КореяСеверные Марианские островаСейшелыСен-БартелемиСен-МартенСен-Пьер и МикелонСенегалСент-Винсент и ГренадиныСент-Китс и НевисСент-ЛюсияСербияСингапурСинт-МартенСирияСловакияСловенияСоломоновы ОстроваСомалиСуданСуринамСьерра-ЛеонеТаджикистанТаиландТайваньТанзанияТогоТокелауТонгаТринидад и ТобагоТувалуТунисТуркменияТурцияТёркс и КайкосУгандаУзбекистанУкраинаУоллис и ФутунаУругвайФарерские островаФиджиФилиппиныФинляндияФолклендские островаФранцияФранцузская ГвианаФранцузская ПолинезияХорватияЦентрально-Африканская РеспубликаЧадЧерногорияЧехияЧилиШвейцарияШвецияШри-ЛанкаЭквадорЭкваториальная ГвинеяЭритреяЭстонияЭфиопияЮжная КореяЮжно-Африканская РеспубликаЮжный СуданЯмайкаЯпония

+7

Это обязательное поле.

Недопустимое значение.

Укажите название компании.

Компания

Stable

Эта информация поможет нам направить ваш запрос консультанту, специализирующемуся на компаниях этой отрасли.

Отрасль*

Stable

Эта информация поможет нам направить ваш запрос консультанту, специализирующемуся на решениях для компаний такого размера.

Количество сотрудников*

Stable

Выберите страну.

Страна*

Да, я хочу получать рассылку Chrome Enterprise с новостями об обновлениях, мероприятиях и другой информацией. Я могу отменить подписку в любое время.

Я разрешаю компании Google звонить мне по указанному номеру телефона в процессе обработки моего запроса

Выберите один вариант.

Отправляя эту форму, я соглашаюсь предоставить свои личные данные и соглашаюсь с тем, что они будут обрабатываться согласно Политике конфиденциальности Google.

Как найти утекшие объекты в дампах памяти Chrome DevTools / Хабр

Меня зовут Андрей, я нефункциональный тестировщик в компании «Тензор». Наш отдел занимается тестированием клиентской производительности веб-приложений Saby. В частности, одно из направлений — тестирование продукта на утечки памяти. Так как у нас большинство приложений Single Page Application, то утечки памяти могут сильно мешать нашим пользователям. Другим уязвимым участком системы является сервер построения HTML (который готовит html-страничку перед отправкой ее клиенту). Он так же, как и SPA-приложение, достаточно долго работает без перезагрузки и поэтому даже небольшая постоянная утечка может превратиться в большое потребление памяти.  Перед отправкой в продакшн мы запускаем автотесты на наличие утечек памяти. В процессе правки найденных утечек мы поняли, что часто разработчики больше времени тратят на локализацию утечки памяти, чем на ее правку.

Почему уходит много времени на локализацию утечки памяти

В сети есть много статей о том, ĸаĸ правильно искать утечки и анализировать полученные дампы памяти. Однако примеры в них сильно упрощены, да и изначально знаешь, в чем утечка и куда смотреть. В реальности дампы памяти, кроме утечки, содержат много «нужных» объектов. Глядя на несколько десятков тысяч объектов одинакового типа, иногда и не знаешь, с чего начать разбор. Например, на рис. 1 ниже показана небольшая утечка при переходе в карточку контакта на сайте contacts.google.com. Утечка менее 100 Кбайт, но при этом создается уже более 10 тысяч объектов. Если сайт сложнее, то объектов может быть еще больше. Поэтому у нас появилась идея облегчить отладку утечек памяти, автоматизировав поиск объектов, которые являются утечкой.

Рис. 1 Пример сравнения дампов с утечкой памяти в одном из продуктов Google. Новых объектов только на скрине уже несколько тысяч при маленьком объеме утечки памяти.Рис.2 Алгоритм теста на утечĸи памяти при построении страницы на сервере

На рис. 2 представлена схема нашего классического теста на утечки памяти. Тестируемым действием может быть как действие пользователя в браузере, так и выполнение какого-либо кода на стороне сервера (Node.js). После 4 повторов тестируемого действия мы получаем 4 дампа памяти (HeapSnapshot, или просто снапшот), которые необходимо проанализировать.

Как мы ищем в дампах памяти объекты, которые утекли

У таких объектов есть несколько характерных признаков:

1. Это должны быть объекты одинакового типа (Object, Array, (string) и т.д).

2. Они должны утекать при каждом повторе действия. Если в одном из повторов нет такого объекта, его уже нельзя назвать утечкой в обычном понимании.

3. У этих объектов должны быть родители одинаковых типов (то есть цепочка Retainers должна быть схожа по виду). Все потому, что утечка происходит из одного и того же места в коде, а значит, контекст возникновения объектов должен быть один и тот же или схожим по виду.

Разберем наглядно. Наш код-пример (рис. 3) создает утечку: в Array при каждом повторе появляется новый Object с другим Object в одном из его параметров. Выделенный кусок кода повторяется 3 раза, после каждого снимается снапшот. И после снятия последнего приступаем к их анализу, выбрав режим Object allocated between snapshots (рис. 4).

Рис. 3 Пример создания утечĸи памятиРис.4 Иллюстрация признаков сходства у объектов утечки

Между 1 и 2 дампом, как и между 2 и 3, создается объект с типом Object. При этом цепочка Retainers у них похожа (Object — Array — system / Context — …), но идентификаторы некоторых объектов различаются.

Так как все признаки утекших объектов присутствуют, то начинать анализ стоило бы именно с выбранных объектов Object @175399 или @175441.

Алгоритм поиска утекших объектов

Итак, после нашего классического теста (рис. 2) у нас 4 снапшота. Что нам надо сделать, чтобы в них найти объекты утечки памяти: 

1. Распарсить снапшоты. Нам надо получить полностью дерево со связями. Раньше мы парсили json самописным сĸриптом, но потом наткнулись на парсер в исходниĸах Chromium и успешно его используем (ссылĸа). Дополнительно он очищает снапшот от различных системных объеĸтов, что упрощает анализ.

2. Отфильтровать объекты, которые удалил GC. Надо найти объеĸты, ĸоторые создались между соседними снапшотами и присутствуют в последнем снапшоте (значит, объеĸт не удален при очистĸах мусора). Исĸать объекты надо по id (в упомянутой либе это параметр object_id, а в devtools это цифры у объекта с @ в начале), они постоянны для одного объеĸта между разными снапшотами. В итоге мы получаем 3 группы объеĸтов: созданные между 1-2 снапшотами, между 2-3 и между 3-4 (на рис. 5 проиллюстрирована схема). 

   Рис.5 Алгоритм первичной фильтрации объектов

3. Отфильтровать системные объекты и объекты с нулевым весом. Предложенный парсер сам убирает системные объекты на этапе парсинга. Объекты с нулевым весом могут присутствовать и в более поздних снапшотах, но это просто пустышĸи. Предполагаем, они нужны для усĸорения V8, но точнее этот вопрос не изучали. Тем не менее, они могут мешать в анализе, так как не являются утечкой памяти.

4. Найти всех родителей. Надо составить все пары «объеĸт — родитель». Используя парсер, сделать это проще простого: у объеĸта связи с его родителями хранятся в переменной edges_to, которые ведут к родительскому объекту.

5. Для каждой пары получить строковое представление их связи. Строковым представлением объекта будет его тип (параметр class_name) — нам надо соединить тип объекта и тип его родителя. Из примера на рис. 4 у объекта с id @175367 тип Object, а у его родителя (объекта с id @136513) — тип Array. Таĸим образом, получится пара Object — Array. Аналогично будет и у объектов @175409 — @136513. Это то, что мы видим в цепочĸе Retainers в DevTools при ручном анализе.

6. Поиск одинаковых пар «объект — родитель» между группами. Это третий признак утечки — у утекаемых объектов должна быть схожая цепочка родителей, так как у них схожий контекст. Если таĸие имеются, это подозрение на утечĸу. Ищем по совпадению строĸи, то есть в нашем примере ищем те же Object — Array в других группах, полученных после 3 шага (рис. 6).

   Рис.6 Поиск объектов со схожими родителями между группами

   На этом этапе выводим в сборке (рис. 7) все найденные пары из первого снапшота с указанием id объектов, в также путь до последнего четвертого снапшота. Сделано так специально, потому что по этим объектам уже много раз прошелся сборщик мусора и у них остались только связи, которые являются утечкой памяти. 

   Далее передаем дело на ручной анализ — разработчику остается только открыть снапшот и проанализировать причину удержания этих объектов в памяти. Последующий анализ не отличается от других методиĸ анализа утечеĸ памяти в JS. 

   Рис. 7 Вывод найденной утечки в сборке

Недостатки алгоритма, которые мы обнаружили

У представленного алгоритма есть несĸольĸо недостатĸов: 

1. Тест относительно долгий (занимает в среднем 5–10 минут). Самой медленной частью является снятие и получение снапшота. Если тестируемое действие у вас выполняется в разы быстрее, чем снятие снапшота, лучше тестировать на утечки в 2 прогона:

2. У алгоритма иногда бывают ложные срабатывания. Чем больше количество снапшотов, тем меньше этих срабатываний, но тем дольше идет тест. Оптимально для нас было выбрано 4 снапшота (не более 5% ложных срабатываний от общего количества тестов). Редкие ложные срабатывания убираются перезапуском теста. Причина заключается в том, что при меньшем количестве снапшотов выше вероятность получить схожие пары «объект — родитель» в каждом снапшоте, которые при этом не будут утечкой. Также не успевают удалиться некоторые объекты, которые не являются мусором, но сидят в памяти для ускорения V8 и удалятся позднее.

Какой профит мы получили от использования описанного алгоритма

1. Сильно облегчили анализ ошибок утечек памяти для разработчиков. Ранее почти для каждой ошибки разработчику приходилось вспоминать азы анализа дампов памяти, затем разворачивать локальную версию продукта, воспроизводить баг. Все это могло занять несколько дней. Теперь в большинстве случаев мы сразу можем указать разработчику, какой объект в каком модуле остается в памяти. Ему остается разобраться в причинах удержания этого объекта. Довольно часто причины тривиальны, и правка много времени не занимает.

2. Можем точнее определить, есть ли утечка. Очень часто Chrome создает системные объекты и держит их в памяти. При анализе только по размеру кучи это может вносить большую погрешность. По внедренному алгоритму мы отсеиваем такие объекты и можем понять, есть ли утечка из несистемных объектов.

Найти Бар

Google Chrome реализует поиск веб-страниц с помощью отображаемой «панели поиска». из правого верхнего (или левого верхнего, в зависимости от языка) угла браузера окно. Панель содержит текстовое поле для ввода условий поиска и некоторые элементы управления для продвижения выбора поиска и закрытия панели.

Это предложение по управлению сроком службы панели поиска. В настоящее время Находка Бар создается и принадлежит WebContentsViewWin, а уникальный поддерживается в соответствии с Tab. FindBar реализован как подкласс WidgetWin, называемый FindBarWin, который является WS_CHILD фрейма. Всякий раз, когда выбранная вкладка изменяется, если вновь выбранная вкладка имеет панель поиска, она становится видимой. Всякий раз, когда вкладка перетащите из окна в другое окно FindBarWin, связанное с этим Вкладка переназначается в новое окно.

Для повышения гибкости API TabContents/WebContents и улучшения последовательность в том, как поддерживаются элементы пользовательского интерфейса браузера Chrome, мы перенос создания и владения битами пользовательского интерфейса браузера Chrome из TabContents и другие объекты и в BrowserView. (Это уже было завершено для TabStrip, панели инструментов браузера, информационных панелей и некоторых других объекты). Класс BrowserView стал классом, представляющим содержимое окна не зависит от типа фрейма. Для получения дополнительной информации об этом прочтите документ Окно браузера. Общая цель этого подхода к проектированию заключается в том, что «представление» в смысле MVC (иерархия объектов, реализующих интерфейс BrowserWindow) способна инициализировать его состояние из набора поддерживающих его объектов модели (Браузер, TabStripModel, TabContents и т. д.).

В свете этого перехода полоса поиска, как часть Пользовательский интерфейс браузера Chrome можно создавать и управлять им вместе с остальной частью пользовательского интерфейса браузера. логичным местом для этого является класс BrowserView, который создает и размещает панели инструментов, информационные панели и другие элементы окна браузера. В этом новом мире экземпляр класса FindBarWin создается для каждого BrowserView в время, когда он добавляется в виджет фрейма и сохраняется в течение всего срока службы этого BrowserView.

Объект WebContents расширен, чтобы обеспечить базовый интерфейс для поиска (который управляет базовым RenderViewHost и WebKit), а также содержит некоторые состояние о последней строке поиска, введенной пользователем, о том, был ли сеанс поиска текущий активен для вкладки, и последний набор результатов поиска, которые были возвращенный из WebKit (в виде объекта FindNotificationDetails, хранящегося как переменная-член).

BrowserView реализует интерфейс TabStripModelObserver, поэтому уведомления о переключении вкладок, добавлениях и удалениях. Всякий раз, когда выбранная вкладка изменения, BrowserView сообщает своему FindBarWin изменить WebContents, который он активен для (если вновь выбранная вкладка является WebContents). Код FindBarWin инициализирует свой пользовательский интерфейс из состояния только что установленного веб-контента, чтобы представление обновляется вместе с Моделью.

Когда приходит время выполнить поиск, код FindBar (в FindBarWin и FindBarView) управляет веб-контентом, к которому он подключен, напрямую, запуская найти сессию.

WebContents реализует интерфейс RenderViewHostDelegate. который включает метод OnFindReply, который вызывается, когда процесс рендеринга возвращается с результатами поиска. WebContents обновляет свои последние сохраненные результаты, а затем уведомляет заинтересованных наблюдателей через уведомление NOTIFY_FIND_RESULT_AVAILABLE:

Затем FindBarWin обновляет свое содержащееся представление (FindBarView) текущим значения результата из WebContents. Это изменение означает, что и пользовательский интерфейс, и поставщик автоматизации (используется для тестов пользовательского интерфейса для поиска на странице) получает свое состояние от такое же уведомление.

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

логика позиционирования для определения состояния родительского BrowserView, чтобы он мог позиционировать себя соответствующим образом. Со старым дизайном это было сложнее, потому что Объект FindBarWin не имел прямого доступа к BrowserView, поэтому ему пришлось выполнить много работы, чтобы выяснить границы различных элементов пользовательского интерфейса браузера и положение относительно них. В новом дизайне реализовано прямое сопоставление 1:1. между FindBarWin и его родительским BrowserView. BrowserView делает макет для всех его дочерних представлений (включая панели инструментов FindBarWin, которые должны располагаться относительно), поэтому в новом дизайне FindBarWin может просто запросить BrowserView, каким должен быть его ограничивающий прямоугольник.

Когда вкладка отсоединяется от одного окна и перемещается в другое, несколько всякое случается. Как в исходном, так и в целевом окнах открыта другая вкладка. выбрано. В исходном окне становится активной другая вкладка и панель поиска для это окно обновляется состоянием этой вкладки, которая может не найти сеанс активен, и в этом случае он будет скрыт.

В целевом окне перетаскиваемый вкладка приведет к тому, что панель поиска этого окна будет инициализирована с состоянием вкладка, которая была вставлена ​​и выбрана. Родные дочерние окна никогда не переназначаются (и, следовательно, в этом дизайне нет переходов диспетчера фокуса).

Когда появляется панель поиска, она уже заполнена искомой строкой. для последнего в этой вкладке. Если предыдущего текста нет, строка поиска не отображается. Описанные здесь изменения прав собственности не влияют на это поведение. WebContents поддерживает новый член find_text_, который отслеживает последний текст, который пользователь искал. В будущем мы хотим изменить это так, чтобы, если нет последняя строка поиска для определенной вкладки, но есть для другой вкладки, тогда мы вместо этого заполните эту строку. Это предложение не влияет на это поведение однако в это время.

Выполнение запросов поиска в длинных документах может занять некоторое время. Обработка результаты операции поиска полностью содержатся на уровне WebContents. Когда запрос инициируется из определенного WebContents, который WebContents получает свои результаты. Когда WebContents получает результаты, он уведомляет заинтересованных наблюдателей, которые могут включать пользовательский интерфейс панели поиска, если эта вкладка активна. При изменении выбранной вкладки штрих-код поиска отменяет регистрацию в качестве наблюдатель уведомлений о результатах поиска, полученных из последнего выбранного веб-контента и регистрируется как наблюдатель уведомления о результатах поиска, полученного из новый. Это гарантирует, что панель поиска будет получать уведомления об обновлениях только от выбранный WebContents, даже если операция поиска ожидает выполнения на нескольких вкладках. Когда пользователь переключается обратно на другую вкладку, панель поиска инициализируется. с текущим состоянием результатов этой вкладки и наблюдайте за любыми будущими результатами в ней до тех пор, пока эта вкладка остается выбранной.

Найдите размеры элемента веб-страницы: TechWeb: Бостонский университет

При добавлении изображений и видео лучше всего делать их не шире, чем нужно. Это помогает сохранить правильный макет дизайна и значительно сокращает время загрузки и загрузки страницы. Следуйте этим инструкциям, чтобы определить размеры любого элемента на веб-странице, включая ширину области содержимого:

Если вы используете стандартную тему Flexi…

1. Ширина области содержимого  550 пикселей во всех стандартных темах Flexi, использующих вариант макета «средний».

Если вы используете пользовательскую тему…

Chrome

1. Используя браузер  Chrome , щелкните правой кнопкой мыши или щелкните, удерживая клавишу Control, в любом месте области содержимого и выберите  Проверить элемент .

   В Chrome щелкните правой кнопкой мыши (или щелкните, удерживая клавишу Control) в области содержимого и выберите «Проверить элемент», чтобы открыть инспектор элементов.

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

   Найдите область содержимого в инспекторе элементов. Он будет выделен синим цветом.

3. Вы увидите всплывающую подсказку рядом с выделением. Первое число — это ширина.

   Ширина элемента будет первой цифрой в желтой подсказке.

Safari

1. Сначала необходимо включить панель инструментов разработчика в браузере. Сделать это:
   1. Откройте Safari Настройки (Mac щелкните Safari и перейдите к Настройки. ПК нажмите Файл и перейдите к Настройки )
   2. Перейдите на вкладку Дополнительно (шестеренка справа)
   3. Выберите Показать меню «Разработка» в строке меню в нижней части этой панели.
   4. Закрыть окно настроек
2. Щелкните правой кнопкой мыши или щелкните правой кнопкой мыши в любом месте области содержимого и выберите  Проверить элемент .
3. В новом окне, которое появляется в нижней части браузера, перемещайте указатель мыши по коду, пока не увидите выделенную область содержимого (обычно синего цвета).
4. Вы увидите всплывающую подсказку рядом с выделением. Первая цифра — ширина.

Firefox

1. Щелкните правой кнопкой мыши или щелкните правой кнопкой мыши в любом месте внутри области содержимого и выберите Проверить элемент .
2. В новом окне, которое появится в нижней части браузера, нажмите кнопку, которая выглядит как курсор мыши, входящий в квадрат.
3. При включенном инструменте Select Element наведите указатель мыши на свой сайт. Вы заметите, что вокруг элементов на странице появляются пунктирные линии. Найдите область содержимого и щелкните, чтобы сфокусироваться на ней.
4. Вернувшись в нижнее окно, нажмите Box Model справа.
5. Будут показаны ширина и высота. Первая цифра — ширина.

Internet Explorer 8 и 9

1. Нажмите F12 , чтобы вызвать Инструменты разработчика.