Skip to content
This repository has been archived by the owner on Jul 29, 2024. It is now read-only.

feat(blockingproxy): Add synchronization with BlockingProxy. #3813

Merged
merged 8 commits into from
Dec 16, 2016

Conversation

heathkit
Copy link
Contributor

This adds support for BlockingProxy behind the flag --useBlockingProxy.

If set, the driver providers will start a proxy during their setup phase, passing the selenium address to the proxy and starting a webdriver client that talks to the proxy.

Starting a proxy for each driver provider isn't strictly necessary. However, when we run with multiple capabilities it's easier to handle the logging if each Protractor instance has it's own proxy.

Known issues:

  • Doesn't work with directConnect. You can get the address of chromedriver by mucking around in Selenium internals, but this probably changed for Selenium 3.0 and I doubt it's worth figuring out until we upgrade.
  • Doesn't yet work with webDriverProxy (but it's an easy fix)
  • Doesn't work with wrapDriver. The new browser instance will need to know somehow that the flag is set, still working on this.

@@ -1,4 +1,6 @@
machine:
node:
version: 6.9.1
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we remove the npm install -g npm@3 now?

import {Config} from './config';
import {Logger} from './logger';

const BP_PATH = 'node_modules/blocking-proxy/built/lib/bin.js';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we use require.resolve here to avoid mucking around with node_modules?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

throw new Error('BlockingProxy not yet supported with directConnect!');
}
}
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Newline please!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

@@ -188,7 +195,21 @@ export class ProtractorBrowser extends Webdriver {
*
* @type {boolean}
*/
ignoreSynchronization: boolean;
set ignoreSynchronization(value) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should take this opportunity to improve the naming here. I think we had discussed waitForAngularEnabled(true/false)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd also be OK with keeping these changes that keep ignoreSynchronization working but adding the new API as the 'recommended way' as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. I'll add the new API, but I'd like to leave ignoreSynchronization in place and announce that it's deprecated.

@@ -668,6 +693,12 @@ export class ProtractorBrowser extends Webdriver {
return 'Protractor.get(' + destination + ') - ' + str;
};

if (this.bpClient) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, why is this necessary? Because we do executeScript calls, and BpClient isn't smart enough to know that it doesn't need to wait for those?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Exactly. We could skip waiting for executeScript calls in general, but I wanted to keep behavior the same.

@@ -72,7 +73,7 @@
},
"license": "MIT",
"engines": {
"node": ">=4.2.x"
"node": ">=6.9.x"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's avoid this change until 5.x

Out of curiosity, what in this PR depends on it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rebased to the beta branch.

@@ -0,0 +1,34 @@
var env = require('./environment.js');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add this to the test.sh script for npm test?

@@ -0,0 +1,34 @@
var env = require('./environment.js');

// The main suite of Protractor tests.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Update comment.


blockingProxyUrl: 'http://localhost:8111',

// Exclude patterns are relative to this directory.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unnecessary.

'hybrid/async_spec.js'
],

blockingProxyUrl: 'http://localhost:8111',
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should be useBlockingProxy: true now

@heathkit heathkit changed the base branch from master to beta December 13, 2016 18:50
@googlebot
Copy link

We found a Contributor License Agreement for you (the sender of this pull request) and all commit authors, but as best as we can tell these commits were authored by someone else. If that's the case, please add them to this pull request and have them confirm that they're okay with these commits being contributed to Google. If we're mistaken and you did author these commits, just reply here to confirm.

@googlebot
Copy link

CLAs look good, thanks!

@heathkit heathkit force-pushed the blockingproxy branch 5 times, most recently from 49c2655 to 7f109ea Compare December 15, 2016 01:27
@googlebot
Copy link

We found a Contributor License Agreement for you (the sender of this pull request) and all commit authors, but as best as we can tell these commits were authored by someone else. If that's the case, please add them to this pull request and have them confirm that they're okay with these commits being contributed to Google. If we're mistaken and you did author these commits, just reply here to confirm.

1 similar comment
@googlebot
Copy link

We found a Contributor License Agreement for you (the sender of this pull request) and all commit authors, but as best as we can tell these commits were authored by someone else. If that's the case, please add them to this pull request and have them confirm that they're okay with these commits being contributed to Google. If we're mistaken and you did author these commits, just reply here to confirm.

} else {
builder = new webdriver.Builder()
.usingServer(this.config_.seleniumAddress)
.usingWebDriverProxy(this.config_.webDriverProxy)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what's blocking us from allowing webdriver proxies (out of curiosity).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nothing really, it just needs to be implemented on the BlockingProxy side. I'm having trouble coming up with a good test for it.

@juliemr
Copy link
Member

juliemr commented Dec 15, 2016

Failing test is the one we decided to kill - so after this is gone and passing, LGTM.

@juliemr juliemr added cla: yes and removed cla: no labels Dec 15, 2016
@juliemr
Copy link
Member

juliemr commented Dec 15, 2016

Dunno why CLA-bot is so unhappy today.

@googlebot
Copy link

CLAs look good, thanks!

1 similar comment
@googlebot
Copy link

CLAs look good, thanks!

@heathkit heathkit merged commit 43502e1 into angular:beta Dec 16, 2016
heathkit added a commit to heathkit/protractor that referenced this pull request Dec 19, 2016
…#3813)

This adds support for BlockingProxy behind the flag --useBlockingProxy.

If set, the driver providers will start a proxy during their setup phase, passing the selenium address to the proxy and starting a webdriver client that talks to the proxy.

Starting a proxy for each driver provider isn't strictly necessary. However, when we run with multiple capabilities it's easier to handle the logging if each Protractor instance has it's own proxy.

Known issues:

- Doesn't work with directConnect. You can get the address of chromedriver by mucking around in Selenium internals, but this probably changed for Selenium 3.0 and I doubt it's worth figuring out until we upgrade.
- Doesn't yet work with webDriverProxy (but it's an easy fix)
juliemr pushed a commit that referenced this pull request Dec 19, 2016
This adds support for BlockingProxy behind the flag --useBlockingProxy.

If set, the driver providers will start a proxy during their setup phase, passing the selenium address to the proxy and starting a webdriver client that talks to the proxy.

Starting a proxy for each driver provider isn't strictly necessary. However, when we run with multiple capabilities it's easier to handle the logging if each Protractor instance has it's own proxy.

Known issues:

- Doesn't work with directConnect. You can get the address of chromedriver by mucking around in Selenium internals, but this probably changed for Selenium 3.0 and I doubt it's worth figuring out until we upgrade.
- Doesn't yet work with webDriverProxy (but it's an easy fix)
juliemr pushed a commit that referenced this pull request Dec 20, 2016
This adds support for BlockingProxy behind the flag --useBlockingProxy.

If set, the driver providers will start a proxy during their setup phase, passing the selenium address to the proxy and starting a webdriver client that talks to the proxy.

Starting a proxy for each driver provider isn't strictly necessary. However, when we run with multiple capabilities it's easier to handle the logging if each Protractor instance has it's own proxy.

Known issues:

- Doesn't work with directConnect. You can get the address of chromedriver by mucking around in Selenium internals, but this probably changed for Selenium 3.0 and I doubt it's worth figuring out until we upgrade.
- Doesn't yet work with webDriverProxy (but it's an easy fix)
juliemr pushed a commit that referenced this pull request Dec 21, 2016
This adds support for BlockingProxy behind the flag --useBlockingProxy.

If set, the driver providers will start a proxy during their setup phase, passing the selenium address to the proxy and starting a webdriver client that talks to the proxy.

Starting a proxy for each driver provider isn't strictly necessary. However, when we run with multiple capabilities it's easier to handle the logging if each Protractor instance has it's own proxy.

Known issues:

- Doesn't work with directConnect. You can get the address of chromedriver by mucking around in Selenium internals, but this probably changed for Selenium 3.0 and I doubt it's worth figuring out until we upgrade.
- Doesn't yet work with webDriverProxy (but it's an easy fix)
juliemr pushed a commit that referenced this pull request Dec 22, 2016
This adds support for BlockingProxy behind the flag --useBlockingProxy.

If set, the driver providers will start a proxy during their setup phase, passing the selenium address to the proxy and starting a webdriver client that talks to the proxy.

Starting a proxy for each driver provider isn't strictly necessary. However, when we run with multiple capabilities it's easier to handle the logging if each Protractor instance has it's own proxy.

Known issues:

- Doesn't work with directConnect. You can get the address of chromedriver by mucking around in Selenium internals, but this probably changed for Selenium 3.0 and I doubt it's worth figuring out until we upgrade.
- Doesn't yet work with webDriverProxy (but it's an easy fix)
juliemr pushed a commit that referenced this pull request Dec 28, 2016
This adds support for BlockingProxy behind the flag --useBlockingProxy.

If set, the driver providers will start a proxy during their setup phase, passing the selenium address to the proxy and starting a webdriver client that talks to the proxy.

Starting a proxy for each driver provider isn't strictly necessary. However, when we run with multiple capabilities it's easier to handle the logging if each Protractor instance has it's own proxy.

Known issues:

- Doesn't work with directConnect. You can get the address of chromedriver by mucking around in Selenium internals, but this probably changed for Selenium 3.0 and I doubt it's worth figuring out until we upgrade.
- Doesn't yet work with webDriverProxy (but it's an easy fix)
sjelin pushed a commit that referenced this pull request Dec 28, 2016
This adds support for BlockingProxy behind the flag --useBlockingProxy.

If set, the driver providers will start a proxy during their setup phase, passing the selenium address to the proxy and starting a webdriver client that talks to the proxy.

Starting a proxy for each driver provider isn't strictly necessary. However, when we run with multiple capabilities it's easier to handle the logging if each Protractor instance has it's own proxy.

Known issues:

- Doesn't work with directConnect. You can get the address of chromedriver by mucking around in Selenium internals, but this probably changed for Selenium 3.0 and I doubt it's worth figuring out until we upgrade.
- Doesn't yet work with webDriverProxy (but it's an easy fix)
juliemr pushed a commit that referenced this pull request Dec 29, 2016
This adds support for BlockingProxy behind the flag --useBlockingProxy.

If set, the driver providers will start a proxy during their setup phase, passing the selenium address to the proxy and starting a webdriver client that talks to the proxy.

Starting a proxy for each driver provider isn't strictly necessary. However, when we run with multiple capabilities it's easier to handle the logging if each Protractor instance has it's own proxy.

Known issues:

- Doesn't work with directConnect. You can get the address of chromedriver by mucking around in Selenium internals, but this probably changed for Selenium 3.0 and I doubt it's worth figuring out until we upgrade.
- Doesn't yet work with webDriverProxy (but it's an easy fix)
@heathkit heathkit deleted the blockingproxy branch January 4, 2017 01:35
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants