ну поставьте любой гуй менеджер туда и проверьте, ей богу.
представьте, что вашим сервисом кто-то с убунту будет пользоваться, и ваш переход по ссылке откроет новый браузер в расширении 800х600. я бы посмеялся, а кто-то плюнет и уйдёт
Не совсем так. Селенид при открытии нового браузера учитывает и параметр Configuration.browserSize
, и chromeoptions.args
. Но только Селенид.
Если добавление chromeoptions.args
повлияло на размер второго окна, это может означать только одно: это второе окно открывалось не автоматически по клику, а его тоже открывал Селенид. Причём с какими-то очень нестандартными настройками (chromeoptions.args
учитывает, а Configuration.browserSize
не учитывает).
здесь вы предлагаете поставить брейкпойнт в методе присвоения значения свойству browserSize, например?
зачем? ставьте дебаг в моменте работы на второй вкладке, и смотрите, что там лежит в переменной драйвера
если оно отличается от того, что вы ожидаете,то надо искать, почему так. может дефолтные значения откуда-то прилетают
Тоже столкнулся с такой проблемой. Я — начинающий автоматизатор, и сценарий в моём случае очень простой: на главной странице проверяется десяток ссылок, ведущих в другие разделы сайта. Все тесты идентичные: открывается главная, нажимается кнопка, проверяется, что открылось то, что должно.
Далее происходит вот что: 6 тестов проходят, а 4 падают — потому что главная начинает открываться размером 800x600
. И такое поведение только в режиме headless
и в CI
. Прописал явно browserSize
— не помогло. А если ещё добавить startMaximized
— во всех тестах окно начинает открываться в 800x600
. Задержка между тестами также не решила проблему, а вот closeWindow
после каждого теста сработало.
Возможно, эта информация чем-то поможет