Closed riabiy closed 1 year ago
@riabiy Do you still have this problem on Chromium v110? Sounds like it might be an issue with Chromium itself. If you can provide replication steps, along with some screenshots, that would be helpful. Thank you!
To be honest, I've stayed at 106.
Seems like it's not something obvious from your end.
I'll make a demo with same real-world setup, where the difference is only versions.
And docker logs. Will see.
@riabiy Do you still have this problem on Chromium v110? Sounds like it might be an issue with Chromium itself. If you can provide replication steps, along with some screenshots, that would be helpful. Thank you!
Video of 2 runs. The only difference between two runs is one line, that I've shown on the video. Even if I'm wrong somewhere in the setup (I don't think so) -> it should stay consistent.
On 106
it opens fully (I use it for now) and on 111
the window opens halfway.
And I can't override that via capabilities. On 106
-> I can.
I actually noticed the same. I fixed it by setting the size manually in DuskTestCast.php:
/**
* Create a new Browser instance.
*
* @param \Facebook\WebDriver\Remote\RemoteWebDriver $driver
* @return \Laravel\Dusk\Browser
*/
protected function newBrowser($driver) {
$browser = new Browser($driver);
return $browser->resize(1920, 1080);
}
@riabiy Thanks for the clarity via the videos, they speak a thousand words. I'll take a look and see if I can replicate the scenario with the Chromium 111 image. To rule out differences between Chromium versions and other dependencies in the image, I'll also take the 106 image and just upload Chromium to the latest and then see if the same thing still happens.
@riably I ran a similar test as what you've done, opening Chromium for about 10 seconds. I used both of these docker commands to start the container:
docker run --rm --shm-size 2g -p 4444:4444 -p 7900:7900 -p 5900:5900 -e SE_SCREEN_WIDTH=1920 -e SE_SCREEN_HEIGHT=1080 seleniarm/standalone-chromium:latest # which is 111.0 currently
docker run --rm --shm-size 2g -p 4445:4444 -p 7901:7900 -p 5901:5900 -e SE_SCREEN_WIDTH=1920 -e SE_SCREEN_HEIGHT=1080 seleniarm/standalone-chromium:106.0
I then ran the basic test using both SeleniumJS, Selenium Python, and WebdriverIO for both the 106 and 111 containers. I get the same result you were getting with 111 in both 106 and 111.
Can you share the OpenGoogleAndWait4Seconds test that you're running? Would it be possible to create a small public repo with that test, and the configuration, which I could clone? Is there perhaps some window sizing that's happening within the test framework to force Chromium to open in full size?
Also, do you want to try your same tests with docker run instead of docker-compose? Let's see if that makes a difference in trying to replicate or discover the cause.
I had a Python and Node.js Selenium WebDriver setup in order to open Chrome in both 106 and 111. There was no differences noted. The browser opens maximized as long as the --start-maximized
option is specified when creating the session.
I noticed you're using PHP, so I got php-webdriver and setup the same test. I'm now able to replicate the problem. It seems that this line only seems to work with the 106 image, not the 111 image:
PHP:
$options->addArguments(['--start-maximized']);
However, with the official Selenium WebDriver language bindings, such as SeleniumJS and Selenium Python, both of the images accept this argument:
JavaScript:
options.addArguments('--start-maximized');
Python:
options.add_argument("--start-maximized")
This seems like it may be an issue in the PHP language bindings, which is maintained here: https://github.com/php-webdriver/php-webdriver. Do you want to open an issue there? You can reference this issue so they have the context.
I've also confirmed the same behavior on the upstream docker-selenium repo with the latest standalone-chrome and the one from 106. Also, I rebuilt the container image that had Chromium 106 and Selenium 4.5.3 with Chromium 111 and Selenium 4.8.1. I discovered the same behavior only after upgrading the Selenium server to 4.8.1. Still, this only seems to affect the language bindings and only for PHP.
I reported this issue here: https://github.com/php-webdriver/php-webdriver/issues/1061
@jamesmortensen thank you A LOT for the work :)
I really appreciate it. Was busy over the weekends. I think it's totally viable to close this bug for now, since it's not exactly a selenium bug.
Thank you!
p.s. feel free to reopen, if you feel, like this is how it should be done :)
Hi @riabiy I didn't get a chance to check it, but does @myMartek workaround work, to resize the browser after it opens? Hope that helps.
Hi @riabiy I didn't get a chance to check it, but does @myMartek workaround work, to resize the browser after it opens? Hope that helps.
I haven't tried, but assume it might help. For now I'm ok with staying on 106
and will use that command as a last resort, since it still takes time to resize during the Selenium run. Tiny fraction, yet on a large suite. It adds up.
Hi @riabiy I didn't get a chance to check it, but does @myMartek workaround work, to resize the browser after it opens? Hope that helps.
tl;dr I'll check, when I'm actively working over the Dusk suite.
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
What happened?
In a nutshell, after moving from 105 to 106 I saw an outrageous 2x speed boost (session started closing faster). But after 108 window stopped being proper size.
Nothing changes, but
standalone-chromium:108.0
/standalone-chromium:106.0
/standalone-chromium:107.0
...Definitely a backwards compatibility issue.
Command used to start Selenium Grid with Docker
Relevant log output
Operating System
macOS latest
Docker Selenium version (tag)
after 108