Remove restrictions on browserName and combining with app capability for Grid #139
Conversation
|
Looks like I'll need to update tests to go along with this, since they explicitly test for these cases. I'd like to get some feedback if possible, before spending the time to do that. |
|
This makes sense to me. Though I'd like to keep the check and emit a warning so people know why there might be odd behavior if they use both caps. Does that sound good to you? |
|
I agree with having a log message that both are set. Otherwise this is fine. |
jessehudl
force-pushed
the
less_restrictive_browsername
branch
from
5dace97
to
b604fc5
Compare
| let msg = 'The desired capabilities should not include both an app and a browser'; | ||
| log.errorAndThrow(msg); | ||
| let msg = 'The desired capabilities should generally not include both an app and a browser'; | ||
| log.warn(msg); |
There was a problem hiding this comment.
Warn instead of throwing an error.
|
@jessehudl LGTM now; can you please squash into one commit? |
| if (caps.browserName && caps.app) { | ||
| let msg = 'The desired capabilities should not include both an app and a browser'; | ||
| log.errorAndThrow(msg); | ||
| let msg = 'The desired capabilities should generally not include both an app and a browser'; |
There was a problem hiding this comment.
Changed message to include the word "generally" since it's not necessarily bad, also make a note in the comment that it's common when using Appium with Selenium Grid.
|
@jlipps I did 2 commits since one of the changes is unrelated to this work and just fixes a typo I noticed. Do you still want me to squash? |
|
Looks like there's an e2e test for this too, I'll squash and remove that one as well. |
jessehudl
force-pushed
the
less_restrictive_browsername
branch
from
b604fc5
to
e26d672
Compare
|
ok, everything looks good now. thanks! i'll let @imurchie do a pass and merge |
… grid This restriction broke compatibility with Selenium Grid where the browserName capability is used to define the node's available simulator/devices. Also remove/modify tests that are affected.
jessehudl
force-pushed
the
less_restrictive_browsername
branch
from
a91c863
to
aa1313d
Compare
|
Sorry guys, I just pushed again. I decided to change the existing unit test to specifically check that this case does pass, so it doesn't break in the future. Just curious, is SauceLabs using Selenium Grid? Since most of the Appium maintainers seem to work for Sauce, I'm wondering if it's actually getting tested in this way. |
|
@jessehudl no, Sauce does not use Selenium grid :-) |
|
@jlipps ah, secret "sauce" huh? 😬 Anyways, everything's passing and should be ready for code review, or merge 😀 |
|
Looks good to me! Thanks for this! And thanks for taking the time to fix the typo! |
This is the android implementation of appium-boneyard/appium-ios-driver#127, which has already been merged.
#19 looks to have added these particular restrictions.
browserNameneeds to be open since that's how the Selenium Grid matches nodes. See appium-boneyard/appium-ios-driver#127 for more details.This PR also had to remove the specific check for providing
browserNameandapptogether, which was not necessary for the iOS PR. I'm not positive what the rationale for this was, I'm assuming to try and catch mistakenly providing both. However providing both still prefersappwith a custombrowserName(which is necessary for the Grid). Another alternative would be to check if this server is being run as a Grid node, to do this conditionally. Perhaps @jlipps can comment since he added these changes?I've left
CHROME_BROWSERSinandroid-helpers.jssince it appears to be used by other things.I've tested these changes with Appium v1.5 locally and with Selenium Grid 2.52.0.