Closed titusfortner closed 1 year ago
@titusfortner we didn't change anything around Set Window Rect
for Marionette in Firefox 104. So this is interesting. Does it only reproduce in CI or do you see the same locally? I would be interested in a trace log, and maybe a more granular regression range with beta releases if you can reproduce.
Oh I missed that you cannot reproduce locally. Maybe you can tweak a CI run to produce some log files. That would be great.
Let me see what I can do there. And it was definitely FF 104, always passed before, always failed after.
Oh, I'm sorry! When I checked the list of fixed bugs I only checked these for the Marionette component but not any other. So especially for this release we had a fix as part of Firefox in https://bugzilla.mozilla.org/show_bug.cgi?id=1780212 which definitely would have caused that for you. The question now is what's wrong with restoring the window from maximized state as what it looks like to be the case here.
I filed as https://bugzilla.mozilla.org/show_bug.cgi?id=1789823. @titusfortner do you actually have a job that doesn't run under xvfb? If yes, does it fail there as well?
I can't duplicate the problem in my Linux VM. Even when I set window.maximize
first.
Do you run the tests with xvfb? I wonder if that's related.
Also do you have a chance to run the job in CI with the MOZ_LOG=Widget:5
environment variable set? It should print details which hopefully will help to diagnose the underlying problem.
@titusfortner any further feedback? We would kinda appreciate a log for widget.
Thanks a lot @titusfortner! Do you know if Firefox starts in fullscreen mode or if the xvfb config for GitHub doesn't have a window manager installed? Maybe that's the reason why Firefox cannot correctly determine and set a specific window state.
[Parent 2499: Main Thread]: D/Widget [7faac303a000]: GetScreenBounds 0,0 -> 1152 x 921, unscaled 0,0 -> 1152 x 921
[Parent 2499: Main Thread]: D/Widget [7faac303a000]: nsWindow::Move to 10 10
[Parent 2499: Main Thread]: D/Widget [7faac303a000]: size state is not normal, bailing
Actually when inspecting the Widget logs a bit further I can see that Firefox gets started automatically in maximized mode. So please drop that part. I'll let an engineer examine the log and hopefully we have some ideas soon. Thanks again!
@titusfortner what is the difference to the Python jobs? They seem to work fine in CI for some of the most recent commits: https://github.com/SeleniumHQ/selenium/actions/runs/3040228998/jobs/4896101362
For these jobs there is also xvfb with DISPLAY: 99
in use. So I wonder what makes the Ruby job special.
As discovered this is only a problem when tests are run with Xvfb and no window manager installed. That's basically a not supported configuration and needs to be fixed in Selenium CI. The following pull request is open from myself that will take care of it:
https://github.com/SeleniumHQ/selenium/pull/11025
Given that this is not a geckodriver issue I'm closing this issue.
FYI this issue got fixed via https://github.com/SeleniumHQ/selenium/pull/11025
Selenium project tests started failing with Firefox v104. I only see it happening on Github, and can't reproduce it locally, even on my Linux VM.
With this code:
This is the exception:
So, the height and width were properly changed, but the x and y values were not.
https://github.com/SeleniumHQ/selenium/runs/8139181072?check_suite_focus=true#step:10:1375