Я работаю над расширением прокси для браузера Chrome. Мое расширение устанавливает конфигурацию прокси-сервера браузера, используя:
chrome.proxy.settings.set({
value: config,
scope: 'regular',
});
Где config использует режим fixed_servers.
Прокси-серверы требуют аутентификации, поэтому у меня есть:
chrome.webRequest.onAuthRequired.addListener(details => {
// Some logic
return {
authCredentials: {
username: usernameValue,
password: passwordValue,
},
};
});
Вплоть до последней 71-й версии Chrome эта логика работала должным образом: Browser boots > extensions initialized > all traffic goes through proxy and auth requests from proxy server are handled by listener.
Начиная с 71-й версии кажется, что браузер не дожидается инициализации расширений (проблема появляется после Hard Quit, то есть при использовании command + Q) и начинает отправлять запросы. Поскольку конфигурация прокси уже установлена: Requests go through proxy > proxy server requests authentication > extension is still not initialized by browser, therefore auth request listener is not added in the background as well - since there is nothing to intercept auth requests - native auth prompt is sown for the user.
Это заканчивается очень плохим UX + спустя несколько мгновений, когда расширение инициализируется, слушатель уже на месте, поэтому пользователь может либо заполнить приглашение и отправить, либо просто отменить - в любом случае прокси-сервер и его авторизация работают.
Ищу выход из этой ситуации. Возможно, есть способ установить некоторую конфигурацию для браузера, которая не позволяет ему выполнять запросы до тех пор, пока не будет инициализировано определенное расширение, или какой-то способ приостановить / сбросить / очистить конфигурацию прокси-сервера перед закрытием браузера (тогда я мог бы снова вручную установить прокси при инициализации). Или любое другое исправление для данной ситуации.
Я уже пробовал использовать методы chrome.windows для отслеживания создания и удаления окон браузера, а при последнем удалении попытался вызвать chrome.proxy.settings.clear({ scope: 'regular' }, function() {...});, но, как я понял, только sync успевает сработать до выхода, а async - нет, следовательно, chrome.proxy.settings.clear() - это бесполезно.
Я заранее благодарен за любые советы, предложения, решения / хаки и т. д.
document_start, открыв синхронный XHR с таймаутом 100 мс для любого внутреннего URL-адреса, такого как ваш манифест, и повторять цикл до тех пор, пока chrome.runtime.connect () не завершится успешно.
Я предполагал, что предыдущие версии не запускали сетевые запросы при инициализации браузера до тех пор, пока расширение не будет инициализировано, потому что несколько расширений прокси используют этот шаблон, и все было хорошо до недавнего выпуска, и, как я тестировал сейчас, не только мое, но в основном все основные расширения прокси, которые use auth затронуты и возникла проблема. Кроме того, мне кажется странным, что это происходит только после «жесткого выхода» с помощью команды + Q. В любом случае, спасибо за предложенное решение, я раскрою его и посмотрю, что можно сделать.
@ MindaugasJačionis Вы должны увидеть, была ли ошибка для этого уже зарегистрирована в crbug.com, и зарегистрировать ее, если это не так. Это определенно звучит как регресс.



![Безумие обратных вызовов в javascript [JS]](https://i.imgur.com/WsjO6zJb.png)


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