// These flags are using in conjunction withusing->used
MarkAsDone(DNS_CONFIGURATIONS);What ensures dns is reset after extensions are done?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Auto-Submit | +1 |
| Commit-Queue | +1 |
// These flags are using in conjunction withThomas Cedenousing->used
Done
MarkAsDone(DNS_CONFIGURATIONS);What ensures dns is reset after extensions are done?
Using the sequence_checker ensures that every method launched in ProfileResetter is launched in sequential order in ResetSettingsImpl, I also manually confirmed this behavior through some debug logging, technically DCHECK_CALLED_ON_VALID_SEQUENCE would fail before this check.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
MarkAsDone(DNS_CONFIGURATIONS);What ensures dns is reset after extensions are done?
Using the sequence_checker ensures that every method launched in ProfileResetter is launched in sequential order in ResetSettingsImpl, I also manually confirmed this behavior through some debug logging, technically DCHECK_CALLED_ON_VALID_SEQUENCE would fail before this check.
The sequence_checker_ doesn't really impact that. What matters is that extensions are cleared first *and* extensions completes synchronously. AFAICT this is what the code does. Given these two constraints, it shouldn't be possible to hit this code. By that I mean pending_reset_flags_ should never contain EXTENSIONS by the time this function is called. Unless I'm missing something I recommend adding a dcheck to that effect.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Auto-Submit | +1 |
| Commit-Queue | +1 |
MarkAsDone(DNS_CONFIGURATIONS);Thomas CedenoWhat ensures dns is reset after extensions are done?
Scott VioletUsing the sequence_checker ensures that every method launched in ProfileResetter is launched in sequential order in ResetSettingsImpl, I also manually confirmed this behavior through some debug logging, technically DCHECK_CALLED_ON_VALID_SEQUENCE would fail before this check.
The sequence_checker_ doesn't really impact that. What matters is that extensions are cleared first *and* extensions completes synchronously. AFAICT this is what the code does. Given these two constraints, it shouldn't be possible to hit this code. By that I mean pending_reset_flags_ should never contain EXTENSIONS by the time this function is called. Unless I'm missing something I recommend adding a dcheck to that effect.
IIUC CHECK is preferred over DCHECK; change is reflected otherwise
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
MarkAsDone(DNS_CONFIGURATIONS);Thomas CedenoWhat ensures dns is reset after extensions are done?
Scott VioletUsing the sequence_checker ensures that every method launched in ProfileResetter is launched in sequential order in ResetSettingsImpl, I also manually confirmed this behavior through some debug logging, technically DCHECK_CALLED_ON_VALID_SEQUENCE would fail before this check.
Thomas CedenoThe sequence_checker_ doesn't really impact that. What matters is that extensions are cleared first *and* extensions completes synchronously. AFAICT this is what the code does. Given these two constraints, it shouldn't be possible to hit this code. By that I mean pending_reset_flags_ should never contain EXTENSIONS by the time this function is called. Unless I'm missing something I recommend adding a dcheck to that effect.
IIUC CHECK is preferred over DCHECK; change is reflected otherwise
Sorry if I wasn't clear. Based on my second comment in this thread I think lines 450-453 should change to:
```
// DNS must be reset after extensions. Extensions are reset first, so by
// the time we get here we should not be waiting on extensions.
CHECK(!(pending_reset_flags_ & EXTENSIONS));
```
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Auto-Submit | +1 |
MarkAsDone(DNS_CONFIGURATIONS);Thomas CedenoWhat ensures dns is reset after extensions are done?
Scott VioletUsing the sequence_checker ensures that every method launched in ProfileResetter is launched in sequential order in ResetSettingsImpl, I also manually confirmed this behavior through some debug logging, technically DCHECK_CALLED_ON_VALID_SEQUENCE would fail before this check.
Thomas CedenoThe sequence_checker_ doesn't really impact that. What matters is that extensions are cleared first *and* extensions completes synchronously. AFAICT this is what the code does. Given these two constraints, it shouldn't be possible to hit this code. By that I mean pending_reset_flags_ should never contain EXTENSIONS by the time this function is called. Unless I'm missing something I recommend adding a dcheck to that effect.
Scott VioletIIUC CHECK is preferred over DCHECK; change is reflected otherwise
Sorry if I wasn't clear. Based on my second comment in this thread I think lines 450-453 should change to:
```
// DNS must be reset after extensions. Extensions are reset first, so by
// the time we get here we should not be waiting on extensions.
CHECK(!(pending_reset_flags_ & EXTENSIONS));
```
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
} flagToMethod[] = {Just a quick nit, now that we rely on the order of the methods here for the dns and proxy resets, leave a comment here as well, so no one accidentally changes the order of the methods here.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Auto-Submit | +1 |
Just a quick nit, now that we rely on the order of the methods here for the dns and proxy resets, leave a comment here as well, so no one accidentally changes the order of the methods here.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Hi Thomas,
The approach LGTM but would it be possible to add a browser test that sets the proxy "from the settings UI" (like ProxyConfigServiceImplTest.NetworkProxy), run PlatfromSanitizeSettings and then check that the proxy is ignored?
"performSanitizeSettings",Sorry if the question is silly, but why remove the callback registration? Isn't this callback still being called from os_sanitize_dialog.ts?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Auto-Submit | +1 |
"performSanitizeSettings",Sorry if the question is silly, but why remove the callback registration? Isn't this callback still being called from os_sanitize_dialog.ts?
This function was re-implemented at the request of an external team, this code removal is just come proactive clean-up on the side: https://chromium-review.googlesource.com/c/chromium/src/+/5649400/27/chrome/browser/ash/sanitize/chrome_sanitize_ui_delegate.cc.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Auto-Submit | +0 |
content::EvalJsResult result =
EvalJs(app_browser->tab_strip_model()->GetActiveWebContents(),
"onPerformSanitize");@acos...@google.com, this is the "non-working" part I'm trying to figure out; after the Sanitize SWA opens it only presents one button that performs this Javascript function (https://source.corp.google.com/h/chrome-internal/codesearch/chrome/src/+/main:ash/webui/sanitize_ui/resources/sanitize_initial.ts;l=52?q=onPerformSanitize&ss=h%2Fchrome-internal%2Fcodesearch%2Fchrome%2Fsrc%2F%2B%2Frefs%2Fheads%2Fmain) in its call stack to initially begin the process. What is the best practice for executing this code for testing?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
content::EvalJsResult result =
EvalJs(app_browser->tab_strip_model()->GetActiveWebContents(),
"onPerformSanitize");@acos...@google.com, this is the "non-working" part I'm trying to figure out; after the Sanitize SWA opens it only presents one button that performs this Javascript function (https://source.corp.google.com/h/chrome-internal/codesearch/chrome/src/+/main:ash/webui/sanitize_ui/resources/sanitize_initial.ts;l=52?q=onPerformSanitize&ss=h%2Fchrome-internal%2Fcodesearch%2Fchrome%2Fsrc%2F%2B%2Frefs%2Fheads%2Fmain) in its call stack to initially begin the process. What is the best practice for executing this code for testing?
Done
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Auto-Submit | +1 |
| Commit-Queue | +1 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Auto-Submit | +1 |
| Commit-Queue | +1 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
| Commit-Queue | +2 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
"Allow proxies for shared networks" in chrome://settings and it's`its`
if (restart_chrome_) {
chrome::AttemptRestart();
}
}Is there any way that we can get the test to set some test global in `chrome::AttemptRestart()`? This CL adds a lot of extra boilerplate in several places, which adds a lot of complexity for a test-only feature.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Auto-Submit | +1 |
| Commit-Queue | +1 |
"Allow proxies for shared networks" in chrome://settings and it'sThomas Cedeno`its`
Done
Is there any way that we can get the test to set some test global in `chrome::AttemptRestart()`? This CL adds a lot of extra boilerplate in several places, which adds a lot of complexity for a test-only feature.
To be honest, the answer is mostly no, there is no global within Chrome::AttemptRestart. Other browser tests who have similar considerations (https://source.corp.google.com/search?q=file:browsertest%20AttemptRestart&ss=h%2Fchromium%2Fchromium%2Fsrc%2F%2B%2Frefs%2Fheads%2Fmain) mainly inject chrome::AttemptRestart as a functional closure during testing. I'll modify the CL since this is slightly cleaner than using bools for control.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
const GURL urls[] = {GURL("http://foo"), GURL("http://bar")};Can you share these constants with line 78? Perhaps a function to return a vector of urls?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Auto-Submit | +1 |
const GURL urls[] = {GURL("http://foo"), GURL("http://bar")};Can you share these constants with line 78? Perhaps a function to return a vector of urls?
I've collated the strings as constexpr - the raw values are used beyond GURL() constructors.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Commit-Queue | +2 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Implement Profile Reset for Proxy Settings
As part of Back to Safety, implements a reset of proxy settings
of the profile tied to the default network, changes
"Allow proxies for shared networks" in chrome://settings and its
associated Shill settings.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |