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 |
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
We should have tests for this.
Not my area (and not for this CL, certainly), but is this a decision we should be trusting the renderer process to make?
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
We should have tests for this.
Not my area (and not for this CL, certainly), but is this a decision we should be trusting the renderer process to make?
Are you asking for tests when the killswitch is enabled? The feature is generally tested by web tests and there are tests in WebRTC as well.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Auto-Submit | +1 |
Commit-Queue | +0 |
Giovanni Ortuno UrquidiWe should have tests for this.
Not my area (and not for this CL, certainly), but is this a decision we should be trusting the renderer process to make?
Are you asking for tests when the killswitch is enabled? The feature is generally tested by web tests and there are tests in WebRTC as well.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Auto-Submit | +0 |
hta: Mind taking a look again? I added tests so need your +1 for that file.
Code-Review | +1 |
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Code-Review | +1 |
Seems a bit iffy to have this big TestCase struct and then compound it with a boolean... but your style choice.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Seems a bit iffy to have this big TestCase struct and then compound it with a boolean... but your style choice.
That's a fair point. I initially considered adding a `loopback_only_param` boolean to the TestCase struct to control the flag's value. I decided against it because every test case would then need to specify that parameter, which felt overly verbose.
Thinking about it more, we could add a `should_request_permission_when_loopback_only` boolean to the struct. It would hold the expected result of ShouldRequestPermission() when the loopback only flag is enabled. This would allows us to merge the two test case arrays into a single, consolidated one, making it clearer which tests behave differently with the flag enabled.
Does that approach seem better to you?
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Giovanni Ortuno UrquidiSeems a bit iffy to have this big TestCase struct and then compound it with a boolean... but your style choice.
That's a fair point. I initially considered adding a `loopback_only_param` boolean to the TestCase struct to control the flag's value. I decided against it because every test case would then need to specify that parameter, which felt overly verbose.
Thinking about it more, we could add a `should_request_permission_when_loopback_only` boolean to the struct. It would hold the expected result of ShouldRequestPermission() when the loopback only flag is enabled. This would allows us to merge the two test case arrays into a single, consolidated one, making it clearer which tests behave differently with the flag enabled.
Does that approach seem better to you?
Yes, that seems like a reasonable approach.
With named-value initialization, it seems that we can avoid cluttering the declaration too much if we add a bool to the struct with a default value.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Giovanni Ortuno UrquidiSeems a bit iffy to have this big TestCase struct and then compound it with a boolean... but your style choice.
Harald AlvestrandThat's a fair point. I initially considered adding a `loopback_only_param` boolean to the TestCase struct to control the flag's value. I decided against it because every test case would then need to specify that parameter, which felt overly verbose.
Thinking about it more, we could add a `should_request_permission_when_loopback_only` boolean to the struct. It would hold the expected result of ShouldRequestPermission() when the loopback only flag is enabled. This would allows us to merge the two test case arrays into a single, consolidated one, making it clearer which tests behave differently with the flag enabled.
Does that approach seem better to you?
Yes, that seems like a reasonable approach.
With named-value initialization, it seems that we can avoid cluttering the declaration too much if we add a bool to the struct with a default value.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |