Block chrome network requests until extension is initialized
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
I am working on proxy extension for chrome browser. My extension sets proxy config of the browser using:
chrome.proxy.settings.set({
value: config,
scope: 'regular',
});
Where config uses fixed_servers mode.
Proxy servers require authentication, therefore I have:
chrome.webRequest.onAuthRequired.addListener(details => {
// Some logic
return {
authCredentials: {
username: usernameValue,
password: passwordValue,
},
};
});
Up until latest 71st Chrome version this logic was working as expected:Browser boots > extensions initialized > all traffic goes through proxy and auth requests from proxy server are handled by listener.
Since 71st version it seems that browser doesn't wait for extensions to be initialized(issue appears after Hard Quit, i.e. using command + Q) and starts sending requests. Since proxy config is already set: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.
This ends up in a very bad UX + moments later when extension gets initialized, listener is already in place, so user either can fill the prompt and submit, or simply cancel - anyway proxy and its auth works.
I am looking for solution for this situation.
Maybe there is a way to set some config for the browser that prevents it from doing requests until certain extension is initialized, or some way to suspend/reset/clear proxy config before browser quit(then I could manually set proxy again on init). Or any other fix for a given situation.
I've already tried to us chrome.windows methods to monitor when browser windows are created and removed and on last one being removed tried calling chrome.proxy.settings.clear({ scope: 'regular' }, function() {...});, but as I figured out, only sync manage to happen before quit, while async do not, hence chrome.proxy.settings.clear() is of no use.
I am thankful in advance for any tips, suggestions, solutions/hacks and etc.
javascript
google-chrome-extension proxy pac proxy-authentication asked Jan 4 at 11:50
Mindaugas JačionisMindaugas Jačionis
57821026
add a comment |
I am working on proxy extension for chrome browser. My extension sets proxy config of the browser using:
chrome.proxy.settings.set({
value: config,
scope: 'regular',
});
Where config uses fixed_servers mode.
Proxy servers require authentication, therefore I have:
chrome.webRequest.onAuthRequired.addListener(details => {
// Some logic
return {
authCredentials: {
username: usernameValue,
password: passwordValue,
},
};
});
Up until latest 71st Chrome version this logic was working as expected:Browser boots > extensions initialized > all traffic goes through proxy and auth requests from proxy server are handled by listener.
Since 71st version it seems that browser doesn't wait for extensions to be initialized(issue appears after Hard Quit, i.e. using command + Q) and starts sending requests. Since proxy config is already set: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.
This ends up in a very bad UX + moments later when extension gets initialized, listener is already in place, so user either can fill the prompt and submit, or simply cancel - anyway proxy and its auth works.
I am looking for solution for this situation.
Maybe there is a way to set some config for the browser that prevents it from doing requests until certain extension is initialized, or some way to suspend/reset/clear proxy config before browser quit(then I could manually set proxy again on init). Or any other fix for a given situation.
I've already tried to us chrome.windows methods to monitor when browser windows are created and removed and on last one being removed tried calling chrome.proxy.settings.clear({ scope: 'regular' }, function() {...});, but as I figured out, only sync manage to happen before quit, while async do not, hence chrome.proxy.settings.clear() is of no use.
I am thankful in advance for any tips, suggestions, solutions/hacks and etc.
javascript
google-chrome-extension proxy pac proxy-authentication asked Jan 4 at 11:50
Mindaugas JačionisMindaugas Jačionis
57821026
I don't know why it was working for you previously, but Chrome always delayed extension background page initialization by design. You can try finding what's changed for your use case via bisecting.
– wOxxOm
Jan 4 at 11:55
2
Content scripts aren't delayed so one possible hack would be to block every page using a content script that runs atdocument_startby opening a synchronous XHR with a 100ms timeout to any internal URL like your manifest, and repeat the loop until chrome.runtime.connect() succeeds.
– wOxxOm
Jan 4 at 12:06
I assumed previous versions were not firing network requests on browser initialization until extension is initialized, because multiple proxy extensions use this pattern and it was all good until recent release, and as I tested now - not only mine, but basically all major proxy extensions that use auth are affected and started having the issue. Also, I find it odd that this happens only after "hard quit" with command + Q. Anyway, thanks a lot for the suggested solution, I'll dig into this and see what can be done.
– Mindaugas Jačionis
Jan 4 at 13:36
2
@MindaugasJačionis You should see if a bug for this was already filed at crbug.com and file it if it wasn't. This definitely sounds like a regression.
– Xan
Jan 4 at 14:17
add a comment |
I am working on proxy extension for chrome browser. My extension sets proxy config of the browser using:
chrome.proxy.settings.set({
value: config,
scope: 'regular',
});
Where config uses fixed_servers mode.
Proxy servers require authentication, therefore I have:
chrome.webRequest.onAuthRequired.addListener(details => {
// Some logic
return {
authCredentials: {
username: usernameValue,
password: passwordValue,
},
};
});
Up until latest 71st Chrome version this logic was working as expected:Browser boots > extensions initialized > all traffic goes through proxy and auth requests from proxy server are handled by listener.
Since 71st version it seems that browser doesn't wait for extensions to be initialized(issue appears after Hard Quit, i.e. using command + Q) and starts sending requests. Since proxy config is already set: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.
This ends up in a very bad UX + moments later when extension gets initialized, listener is already in place, so user either can fill the prompt and submit, or simply cancel - anyway proxy and its auth works.
I am looking for solution for this situation.
Maybe there is a way to set some config for the browser that prevents it from doing requests until certain extension is initialized, or some way to suspend/reset/clear proxy config before browser quit(then I could manually set proxy again on init). Or any other fix for a given situation.
I've already tried to us chrome.windows methods to monitor when browser windows are created and removed and on last one being removed tried calling chrome.proxy.settings.clear({ scope: 'regular' }, function() {...});, but as I figured out, only sync manage to happen before quit, while async do not, hence chrome.proxy.settings.clear() is of no use.
I am thankful in advance for any tips, suggestions, solutions/hacks and etc.
javascript
google-chrome-extension proxy pac proxy-authentication asked Jan 4 at 11:50
Mindaugas JačionisMindaugas Jačionis
57821026
I am working on proxy extension for chrome browser. My extension sets proxy config of the browser using:
chrome.proxy.settings.set({
value: config,
scope: 'regular',
});
Where config uses fixed_servers mode.
Proxy servers require authentication, therefore I have:
chrome.webRequest.onAuthRequired.addListener(details => {
// Some logic
return {
authCredentials: {
username: usernameValue,
password: passwordValue,
},
};
});
Up until latest 71st Chrome version this logic was working as expected:Browser boots > extensions initialized > all traffic goes through proxy and auth requests from proxy server are handled by listener.
Since 71st version it seems that browser doesn't wait for extensions to be initialized(issue appears after Hard Quit, i.e. using command + Q) and starts sending requests. Since proxy config is already set: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.
This ends up in a very bad UX + moments later when extension gets initialized, listener is already in place, so user either can fill the prompt and submit, or simply cancel - anyway proxy and its auth works.
I am looking for solution for this situation.
Maybe there is a way to set some config for the browser that prevents it from doing requests until certain extension is initialized, or some way to suspend/reset/clear proxy config before browser quit(then I could manually set proxy again on init). Or any other fix for a given situation.
I've already tried to us chrome.windows methods to monitor when browser windows are created and removed and on last one being removed tried calling chrome.proxy.settings.clear({ scope: 'regular' }, function() {...});, but as I figured out, only sync manage to happen before quit, while async do not, hence chrome.proxy.settings.clear() is of no use.
I am thankful in advance for any tips, suggestions, solutions/hacks and etc.
javascript
google-chrome-extension proxy pac proxy-authentication javascript
google-chrome-extension proxy pac proxy-authentication asked Jan 4 at 11:50
Mindaugas JačionisMindaugas Jačionis
57821026
asked Jan 4 at 11:50
Mindaugas JačionisMindaugas Jačionis
57821026
asked Jan 4 at 11:50
Mindaugas JačionisMindaugas Jačionis
57821026
asked Jan 4 at 11:50
Mindaugas JačionisMindaugas Jačionis
57821026
asked Jan 4 at 11:50
Mindaugas JačionisMindaugas Jačionis
57821026
57821026
I don't know why it was working for you previously, but Chrome always delayed extension background page initialization by design. You can try finding what's changed for your use case via bisecting.
– wOxxOm
Jan 4 at 11:55
2
Content scripts aren't delayed so one possible hack would be to block every page using a content script that runs atdocument_startby opening a synchronous XHR with a 100ms timeout to any internal URL like your manifest, and repeat the loop until chrome.runtime.connect() succeeds.
– wOxxOm
Jan 4 at 12:06
I assumed previous versions were not firing network requests on browser initialization until extension is initialized, because multiple proxy extensions use this pattern and it was all good until recent release, and as I tested now - not only mine, but basically all major proxy extensions that use auth are affected and started having the issue. Also, I find it odd that this happens only after "hard quit" with command + Q. Anyway, thanks a lot for the suggested solution, I'll dig into this and see what can be done.
– Mindaugas Jačionis
Jan 4 at 13:36
2
@MindaugasJačionis You should see if a bug for this was already filed at crbug.com and file it if it wasn't. This definitely sounds like a regression.
– Xan
Jan 4 at 14:17
add a comment |
I don't know why it was working for you previously, but Chrome always delayed extension background page initialization by design. You can try finding what's changed for your use case via bisecting.
– wOxxOm
Jan 4 at 11:55
2
Content scripts aren't delayed so one possible hack would be to block every page using a content script that runs atdocument_startby opening a synchronous XHR with a 100ms timeout to any internal URL like your manifest, and repeat the loop until chrome.runtime.connect() succeeds.
– wOxxOm
Jan 4 at 12:06
I assumed previous versions were not firing network requests on browser initialization until extension is initialized, because multiple proxy extensions use this pattern and it was all good until recent release, and as I tested now - not only mine, but basically all major proxy extensions that use auth are affected and started having the issue. Also, I find it odd that this happens only after "hard quit" with command + Q. Anyway, thanks a lot for the suggested solution, I'll dig into this and see what can be done.
– Mindaugas Jačionis
Jan 4 at 13:36
2
@MindaugasJačionis You should see if a bug for this was already filed at crbug.com and file it if it wasn't. This definitely sounds like a regression.
– Xan
Jan 4 at 14:17
I don't know why it was working for you previously, but Chrome always delayed extension background page initialization by design. You can try finding what's changed for your use case via bisecting.
– wOxxOm
Jan 4 at 11:55
I don't know why it was working for you previously, but Chrome always delayed extension background page initialization by design. You can try finding what's changed for your use case via bisecting.
– wOxxOm
Jan 4 at 11:55
2
2
Content scripts aren't delayed so one possible hack would be to block every page using a content script that runs at
document_start by opening a synchronous XHR with a 100ms timeout to any internal URL like your manifest, and repeat the loop until chrome.runtime.connect() succeeds.– wOxxOm
Jan 4 at 12:06
Content scripts aren't delayed so one possible hack would be to block every page using a content script that runs at
document_start by opening a synchronous XHR with a 100ms timeout to any internal URL like your manifest, and repeat the loop until chrome.runtime.connect() succeeds.– wOxxOm
Jan 4 at 12:06
I assumed previous versions were not firing network requests on browser initialization until extension is initialized, because multiple proxy extensions use this pattern and it was all good until recent release, and as I tested now - not only mine, but basically all major proxy extensions that use auth are affected and started having the issue. Also, I find it odd that this happens only after "hard quit" with command + Q. Anyway, thanks a lot for the suggested solution, I'll dig into this and see what can be done.
– Mindaugas Jačionis
Jan 4 at 13:36
I assumed previous versions were not firing network requests on browser initialization until extension is initialized, because multiple proxy extensions use this pattern and it was all good until recent release, and as I tested now - not only mine, but basically all major proxy extensions that use auth are affected and started having the issue. Also, I find it odd that this happens only after "hard quit" with command + Q. Anyway, thanks a lot for the suggested solution, I'll dig into this and see what can be done.
– Mindaugas Jačionis
Jan 4 at 13:36
2
2
@MindaugasJačionis You should see if a bug for this was already filed at crbug.com and file it if it wasn't. This definitely sounds like a regression.
– Xan
Jan 4 at 14:17
@MindaugasJačionis You should see if a bug for this was already filed at crbug.com and file it if it wasn't. This definitely sounds like a regression.
– Xan
Jan 4 at 14:17
add a comment |
0
active
oldest
votes
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54038433%2fblock-chrome-network-requests-until-extension-is-initialized%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54038433%2fblock-chrome-network-requests-until-extension-is-initialized%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
I don't know why it was working for you previously, but Chrome always delayed extension background page initialization by design. You can try finding what's changed for your use case via bisecting.
– wOxxOm
Jan 4 at 11:55
2
Content scripts aren't delayed so one possible hack would be to block every page using a content script that runs at
document_startby opening a synchronous XHR with a 100ms timeout to any internal URL like your manifest, and repeat the loop until chrome.runtime.connect() succeeds.– wOxxOm
Jan 4 at 12:06
I assumed previous versions were not firing network requests on browser initialization until extension is initialized, because multiple proxy extensions use this pattern and it was all good until recent release, and as I tested now - not only mine, but basically all major proxy extensions that use auth are affected and started having the issue. Also, I find it odd that this happens only after "hard quit" with command + Q. Anyway, thanks a lot for the suggested solution, I'll dig into this and see what can be done.
– Mindaugas Jačionis
Jan 4 at 13:36
2
@MindaugasJačionis You should see if a bug for this was already filed at crbug.com and file it if it wasn't. This definitely sounds like a regression.
– Xan
Jan 4 at 14:17