I have selenium Hub as a service on Cluster Kubernetes and I start testing remotely using selenium side runner. Unfortunately when I try to run a test with terminal (using Ubuntu), I get the following error:
enter image description here
UnsupportedOperationError: pointer movements relative to viewport are
not supported in bridge mode
at executeLegacy (../../../../../usr/lib/node_modules/selenium-side-runner/node_modules/selenium-webdriver/lib/input.js:1129:17)
at Actions.perform
(../../../../../usr/lib/node_modules/selenium-side-runner/node_modules/selenium-webdriver/lib/input.js:971:16
if I try to start the tests from selenium ide, everything works well. What can the error depend on?
Can you help me? Thank you in advance.
Best regards
This error message...
UnsupportedOperationError: pointer movements relative to viewport are not supported in bridge mode
at executeLegacy (../../../../../usr/lib/node_modules/selenium-side-runner/node_modules/selenium-webdriver/lib/input.js:1129:17)
at Actions.perform (../../../../../usr/lib/node_modules/selenium-side-runner/node_modules/selenium-webdriver/lib/input.js:971:16
...implies that the pointer movement which happens relative to the viewport is not supported while working within a canvas in bridge mode.
As per the documentation in Clause 6 of Class Actions:
For W3C actions, move offsets relative to a WebElement are interpretted relative to the center of an element's first client rect in the viewport. For legacy actions, element offsets are relative to the top-left corner of the element's bounding client rect. When translating actions to the legacy protocol in bridge mode, an extra command must be inserted to translate move offsets from one frame of reference to the other. This extra command conributes to the overall latency issue.
You can find a detailed discussion in Is it possible to programmatically determine whether W3C action commands are used?
This is a known issue with Selenium and is being tracked through Not correctly move pointer to the position inside of element in bridge mode.
ChromeDriver - Implement Actions API
The currently released ChromeDriver 76.0.3809.12 contains the implementation of Actions API.
----------ChromeDriver 76.0.3809.12 (2019-06-07)----------
Supports Chrome version 76
Resolved issue 1897: Implement Actions API [Pri-1]
Link to Issue 1897: Implement Actions API
Switching to ChromeDriver 76.0 will solve your issue.
It could be due to selenium version. I faced the same issue and upgraded selenium version to 4.0.X.
Related
I am trying to convert vk_raytrace to headless so that I can run it via commandline and dump rendered image. I am new to vulkan and saw that vulkan supports headless surface. My first approach was to replace the surface created using glfw window to a headless surface. However, I get VK_ERROR_EXTENSION_NOT_PRESENT for VK_EXT_headless_surface. Next I tried removing surface and swapchain related logic and create frame buffers with image view as attachment. Haven't had any luck with that either.
Any pointers on this would be very helpful.
We have an open bug in our Automation Testing Framework regarding the resizing limitations of a Chrome Window when it is controlled by Selenium + ChromeDriver and I need help since I can't track down an official answer. As far as I am aware this was not an issue in the past.
We currently use the framework Codeception as the base for our own framework and when we use the action resizeWindow with the dimensions 320x568 it resizes the window to 445x500. Has anyone else ran into this issue with Chrome? It looks like a hardcoded limit at this point. Any advice would be greatly appreciated. Below I've provided a few Tests that I've ran looking for the upper and lower limits of the resizing action.
Test #1
Requested Size: 320x568
Resulting Size: 445x500
Test #2
Requested Size: 5000x5000
Resulting Size: 858x5000
Test 3
Requested Size: 1x1
Resulting Size: 252x500
LINKS
Codeception
Codeception - resizeWindow
Magento Functional Testing Framework
I found an answer to my question in another StackOverflow question.
"Chrome cannot resize horizontally below 400px (OS X) or 218px (Windows)"
Browser doesn't scale below 400px?
Can you please try with selenium dimension import
Import : import org.openqa.selenium.Dimension;
code :
Dimension d = new Dimension(320,568);
driver.manage().window().setSize(d); //Resize current window to the set dimension
Try using firefox. It works great. since chrome's setting changed and it won't work for testing media queries unless you use the dev tools.
I'm trying to figure out how to hide the border (including the address bar, tabs, title bar... everything that isn't the browser viewport) of my Firefox instance instantiated by Selenium.
If there's some way to have it use a userChrome.css, that would be straightforward enough. I've tried loading a profile folder that included a userChrome.css using this answer as a guide, but it seemed to ignore the styles. I've also looked through Firefox's about:config to see if there's some preference that would hide the frame of the window, but I haven't found anything yet.
Any solution that allows me to hide all or some of these elements when creating the instance with Selenium would be helpful. I know it's silly, but that's how it goes sometimes, you know?
-edit-
I don't think the title bar needs to be hidden. But everything else should be hidden.
-another edit to clarify a few things-
I mentioned kiosk mode in the comments as an example of the sort of thing I'm going for. Kiosk mode isn't exactly what I'm looking for, though. The windows aren't meant to be fullscreen, but they should still lack the elements of a common browser window. Think of it as like an Electron app. Out of the box, Electron lacks an address bar, tabs, etc. That's basically what we have for our app, but it's with regular-old Firefox. Again, whether these elements are displayed or not doesn't typically impact the test, but we want them hidden anyway.
Finally, I a friend of mine tried achieving this goal using a userChrome.css wrapped in a Firefox profile and was able to get Selenium to use the userChrome. So perhaps I need to figure out what I'm doing wrong. The biggest difference between how he did it and how I'm doing it is I must use a remote web driver for testing. But even still, it should be able to load the userChrome.css file. I'll try to update this question with more details as I fiddle with it some more.
-edit-
I think the reason userChrome isn't working when specifying a profile is because of the version(s) of Selenium/Geckodriver/Firefox being used.
The geckodriver version I started with was 0.15. 0.17 behaved exactly the same. 0.18 didn't respect the profile I passed along to it at all and instead had Firefox open the profile selection window (not very useful, but I was able to at least select the correct profile and see the userChrome.css get applied). 0.24 is no different.
Firefox is 52.9.0. Not much I can do about that.
We're using selenium (standalone) server 3.8.1. Switching out for 3.141.59 Didn't change anything.
Unless there's a version combination that will work with Firefox 52, I think the only thing I can do is wait until there's an update.
At last I have figured it out. In order to get Selenium to use my custom profile, I needed to do the following:
FirefoxProfile profile = new FirefoxProfile(new File(path_to_profile));
FirefoxOptions options = new FirefoxOptions().setProfile(profile);
RemoteWebDriver driver = new RemoteWebDriver(options.toCapabilities());
driver.get(url_of_webpage);
Thanks to avinesh09 on Github for the info I needed to solve the problem. It's so simple, but this has to be the only way that I neglected to try to load the profile.
If fullscreen (kiosk) mode is what you ask for (as then all you see is the viewport) it is as simple as:
driver.manage().window().fullscreen();
It is the same user experience as pressing "F11" in your browser.
This question is a part of another question I asked. However, I already found the answer to this part and thought it would be useful for other people as well.
Part of my other question:
I am using serenity in combination with cucumber for automated screen tests and want to include full-page screenshots in my serenity report. The screenshots in the report are normally only a capture of the viewport. Oftentimes however, this doesn't provide enough information as this is only a part of the screen.
I found that the capturing of serenity screenshots is a part of driver implementation. As most drivers conform with the W3C definition of screenshots those drivers only capture the current viewport.
tl;dr: use FirefoxDriver
I contacted David Burns of W3C. He was very helpful and his answer cleared up a lot for me.
First of all, FirefoxDriver for now still takes screenshots of the full page. David said:
FirefoxDriver (and in Marionette our W3C webdriver implementation) on the otherhand does screenshots by dumping the Document into a canvas and calling a Firefox specific API on Canvas to get a screenshot. Since we dump the entire document we can do full page screenshots. This however may change when we start putting more of the Servo code into Firefox and the way we can access screenshots changes.
So unfortunately this will probably change in the future, but for now it is good (when you use FFdriver)..
He also explains why this choice has been made and references to a talk he gave about how the rendering of webpages works.
Later in our conversation he also referenced to the minutes of the discussion about how screenshots should be captured.
His full answer:
Hi
The tl;dr; is its really hard take fullscreen shots since not all browsers have the information to create a screenshot of the whole page.
Long version:
At Selenium Conf this year I did a talk about how #isDisplayed can sometimes lie to you and the reason is the same as the screenshots. To make browsers appear to make web pages load as fast as possible they workout what needs to be rendered in the view port and then render it, via doing calculations on the CPU or GPU.
Because of this approach it means that browsers build up a display list of certain areas and creates "tiles" to render. It starts from the viewport and works out. Now, a browser is not going to render a whole page at a time, it will have a few times above and below ready for when you scroll and calculate the rest when you scroll.
Now ChromeDriver and Microsoft's EdgeDriver both do their screenshots from the display list and have internal APIs that only give them the viewport. This is because their reference tests (or reftests as they are known to vendors) only care about that. They both don't feel its worth the effort to do the rest because of the edge cases.
FirefoxDriver (and in Marionette our W3C webdriver implementation) on the otherhand does screenshots by dumping the Document into a canvas and calling a Firefox specific API on Canvas to get a screenshot. Since we dump the entire document we can do full page screenshots. This however may change when we start putting more of the Servo code into Firefox and the way we can access screenshots changes.
Because we only know the viewport info it leads to us then having to stitch images together to get a full page screenshot. Both ChromeDriver and IEDriver do this and both development teams consider this an ugly hack because its not always right and there isnt much they can do to make it right.
I hope that helps and explains it well. I suggest watching my talk as I explain how renders and layout engines work in Browsers.
David
I am using FireBreath to create a cross browser plugin which makes use of some native libraries for the respective platform (some .NET based DLLs for Windows and Objective-C based dylibs/frameworks for Mac). Native libraries display UI screens. In order to improve usability, if the user has a multi/extended monitor setup, i would like the native UIs to appear on the same screen as the browser window is currently on.
If an identifier to the monitor with the browser window can be retrieved, that can be passed down to the native components which can be configured to display their UIs on that monitor. I have used FireBreath's getWindowPosition() method to get the rect coordinates of the plugin and used that info to identify the correct monitor in the Windows platform.
However, the coordinates returned in Mac seems to be always 0 (or 1) irrespective of monitor on which the browser window currently resides. I understand that we have to configure an event model and a drawing model in order for this to work in Mac. I have tried following event/drawing model combinations without much success.
1) Cocoa/CoreGraphics
2) Carbon/CoreGraphics
Any help in this regard is much appreciated. Also please do share if there are other approaches to achieve the same. What i want to achieve is to identify the monitor on which the current active browser window resides in Mac. I am unsure at this point, but it maybe possible to achieve this at Objective-C level (without any changes at FireBreath level). Also please note that i want to support Safari, Firefox and Chrome browsers.
You won't like this answer, but simply put you can't do that on Mac. The problem is that with CoreGraphics you are only given a CGContextRef to work with, and it doesn't know where it will be drawn. It was technically possible in older browsers to get an NSWindow by exploiting some internal implementation details, but many browsers that's no longer possible and it was never supported.
Other drawing models are the same; CoreAnimation you have a CALayer but it doesn't know which screen or monitor it is drawn to. I personally think it's a bit annoying as well, but I do not know of any way to find out which monitor your plugin is rendered to, particularly since most of them actually copy the buffer to something else and render in a different process.
I did manage to come up with a workaround and i am just replying here for the completeness of the thread. As #taxilian explained, it is not possible to retrieve plugin coordinates using the window reference. As an alternative approach, Javascript 'Window' object has 2 properties called 'screenX' and 'screenY' that return X and Y coordinates of the browser window relative to the screen. If the user has an extended monitor setup, these are the absolute coordinates with respect to the full extended screen. We can use these values to determine the monitor with the browser window (if the X coordinate is outside the bounds of the primary monitor's width, then the browser should essentially be on the extended monitor). We can retrieve DOM properties from Firebreath as explained in the following link:
http://www.firebreath.org/display/documentation/Invoking+methods+on+the+DOM