Remove safari-only restriction for browserName capability

[jessehudl]

Fixes appium/appium/issues/6412
#5 added desired capabilities restraints, which restrict the allowed browserName for iOS to be only one of ['Safari', 'safari']. However, the Appium docs have long recommended using browserName as a way to specify the type of simulator/device being used, as shown in the example Grid node configuration:

          "browserName": "<e.g._iPhone5_or_iPad4>",

This means existing Selenium Grid -> Appium node configurations using browserName to specify node sessions in this way are effectively incompatible with Appium v1.5 since you now get the error:

[BaseDriver] SessionNotCreatedError: A new session could not be created. Details: The desiredCapabilities object was not valid for the following reason(s): browserName iPhone 6s is not included in the list.

Removing the specific [Ss]afari browserName restriction allows the Selenium grid to find the node properly, in which case the desired caps are passed along to the Appium server and browserName is ignored (since the app capability takes precedence). The restrictions may overall be a good thing and catch misconfigurations, but I think they should be backwards compatible with existing implementations. There is not really an alternative for Selenium Grid to be able to match nodes that I know of aside from using the catch-all applicationName capability, which is not well documented and requires modifying existing configurations.

I've tested this with Appium v1.5.1 and Selenium Grid 2.52.0. Will follow-up for appium-android-driver if this is accepted.

[jessehudl]

I think the build/status check is stuck, it's been pending for over a week.

[jessehudl]

I noticed the stuck build was cancelled, so I triggered a new build with some empty commits, I'm getting the keyboard test failing:

  87 passing (19m)
  1 pending
  1 failing

  1) testapp - keyboard typing should send backspace key:

      AssertionError: expected 'a' to equal 'ab'
      + expected - actual

      -a
      +ab

      at Suite.callee$2$0$ (test/e2e/testapp/keyboard-specs.js:79:41)
      at tryCatch (node_modules/babel-runtime/regenerator/runtime.js:67:40)
      at GeneratorFunctionPrototype.invoke [as _invoke] (node_modules/babel-runtime/regenerator/runtime.js:315:22)
      at GeneratorFunctionPrototype.prototype.(anonymous function) [as next] (node_modules/babel-runtime/regenerator/runtime.js:100:21)
      at GeneratorFunctionPrototype.invoke (node_modules/babel-runtime/regenerator/runtime.js:136:37)
      at run (node_modules/babel-runtime/node_modules/core-js/library/modules/es6.promise.js:104:47)
      at node_modules/babel-runtime/node_modules/core-js/library/modules/es6.promise.js:115:28
      at flush (node_modules/babel-runtime/node_modules/core-js/library/modules/$.microtask.js:19:5)

This change should not affect that at all. Should I push another commit to trigger another build?

[imurchie]

I've manually triggered the build, and am keeping an eye on it.

[imurchie]

I agree old ways of doing things should be supported until there is a better way. Thanks for delving into the problem and coming up with a fix!

[imurchie]

Build works fine now. Can you squash this into a single commit? Then I can merge.

[jessehudl]

@imurchie squashed into a single commit, thanks!

[jessehudl]

Also, I don't think this triggered a new build since the original commit is the same as the original one that was stuck/cancelled. I don't have the ability to trigger a new one (if it's needed).

[jessehudl]

I changed the commit to force a build just in case, so we don't have to keep playing tag. Hopefully it passes 🙏

[imurchie]

Thanks for this!