Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Meta-desired capabilities support & using default desired capabilities #54

Open
aik099 opened this issue Dec 13, 2024 · 0 comments
Open

Comments

@aik099
Copy link
Member

aik099 commented Dec 13, 2024

Current implementation

Currently, the desired capabilities array/object is built from these sources (in a given order):

  1. WebDriver (external library) browser-specific defaults (WebdriverClassicDriver::getBrowserSpecificCapabilities), which do no harm currently because they set only browserName and platform keys in the final array:
case WebDriverBrowserType::CHROME:
            case WebDriverBrowserType::GOOGLECHROME:
                return DesiredCapabilities::chrome();
  1. driver-specific browser-agnostic defaults from WebdriverClassicDriver::DEFAULT_CAPABILITIES['default'] public constant
'default' => [
            'platform' => 'ANY',
            'name' => 'Behat Test',
            'deviceOrientation' => 'landscape',
            'deviceType' => 'desktop',
        ],
  1. driver-specific & browser-specific defaults from WebdriverClassicDriver::DEFAULT_CAPABILITIES['{normalized browser name}'] public constant
WebDriverBrowserType::CHROME => [
            'goog:chromeOptions' => [
                // disable "Chrome is being controlled.." notification bar
                'excludeSwitches' => ['enable-automation'],
                'args' => array(
                    // disable browser folder cloning on Mac, when tests are executed
                    'disable-features=MacAppCodeSignClone', // From https://github.com/minkphp/webdriver-classic-driver/pull/53 (to be merged)
                ),
            ],
        ],
...

Such an approach has an implementation bug that prevents WebDriver (external library) browser-specific defaults defined capabilities from being overwritten (the browserName and the platform in this case), which is addressed in #51.

P.S.
The MinkSelenium2Drver has 2 desired capability defaults: browserName and name. Therefore such a problem doesn't have such an impact there.

Problem 1

No support for nested array merging. For example, I want to keep the goog:chromeOptions array from driver-specific & browser-specific defaults but only add a binary sub-key to it. I can't and I have to redefine all of it.

Problem 2

No meta capabilities support. For example, to enable headless testing in different browsers we need to specify different sets of desired capabilities. We want to make it easier for developers to enable this.

'moz:firefoxOptions' => array(
    'args' => array(
        '--headless',
        '--width=1550',
        '--height=1160',
    ),
),
'goog:chromeOptions' => array(
    'args' => array(
        '--headless',
        // '--window-size=1550,1160', // doesn't work (for me)
        '--start-maximized', // works
    ),
),

Problem 3

Ability to exclude default desired capability defaults (or parts of them) from final desired capabilities array. We do try to provide sensible defaults, but as @oleg-andreyev mentioned in the #53 (comment) that might not be sensible enough for all users.

Solutions (I'm open to suggestions):

Support mink:browserOptions (or any non-standard key), that inside would have feature flags (maybe parametrized as well) that would impact how final array is built.

Possible options:

  • use_web_driver_defaults => true // default value
  • use_mink_driver_defaults => true // default value
  • width => 123
  • height => 456
  • headless => true
  • ...

The goog:chromeOptions.args key needs special handling, because you can have arguments, that have a comma-separated list of values (e.g. disable-features=MacAppCodeSignClone,...) in defaults and the developer might want to add-up/remove-from them.

P.S.
This issue is created to avoid much offtopic in the #53 .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant