CONTROL Key Chords Not Working to open new tabs and windows #786
Comments
|
I think this was fixed in https://bugzilla.mozilla.org/show_bug.cgi?id=1367430, but you tested with an old Firefox. Can you try again with 55 or greater? |
|
Still an issue in 55.0b2. |
|
Paging @mjzffr who has done work in this area. |
|
@BrandonDude Hey, thanks for checking it in 55. I need some more information from you. I need to see the request your client is making to the actions endpoint, but the trace log you originally posted seems to be truncated. Please post [a portion of] a log that shows at least shows the request payload like: The other thing I'm wondering is whether this happens for only certain categories of key combinations. So for example you could compare the behaviour of Ctrl+n on the body, versus Ctrl+a in a text input. |
|
Here are the new logs. Ctrl+a also did nothing.
|
|
Hello, how can I help with this ? I'd made a python script to reproduce the problem using the RemoteWebDriver. Can you check the settings ? Do you have some other test script to reproduce it ? The server side (selenium) log during initialization: On the other side the script sets the python log level to DEBUG, so I get the requests made to the server. I did also try to send the corresponding action chains: and the selenium log for that error: Is that normal ? |
|
Ok I have now reproduced the test case In Java. In order see if it was just a problem of the python binding implementation. The problem still happens. Geckodriver: 0.18.0 My setup was like this one, but for Linux. The log is the following: |
|
Also could SeleniumHQ/selenium#2106 also be related with the problem ? |
|
I have been trying to look more info that can help you. I did make these Marionette tests and verified that it it seems to be not the same case that #646 The SHIFT key seem to work for marionette, but the CONTROL key not. Maybe is a new restriction of firefox? As long as I understood, they try to use all the window-related operations via chrome context. Look here in the section: Important Concepts.
Under those precepts, maybe it is not allowed now that an event sent to an element of the content result in an action at chrome level. How are those concepts mapped to the Webdriver standard ? |
|
Holding down control is supposed to be possible in content context and this is supposed to affect the subsequent keys’ modifier state. However, it is not supposed to be possible to interact with the surrounding system or the browser chrome—such as system menus, other applications, the context menu, or browser controls—when using this API from content. When Marionette is in chrome context mode you gain additional privileges that lets you interact with XUL windows and XUL widgets. Chrome space in Firefox is just another web document with a DOM from which you can locate buttons and menus using the same primitives you would normally use with WebDriver for web content. Within this context it is possible to also interact with Firefox UI. Internally, Marionette uses nsIDOMWindowUtils to synthesise event. This bypasses the operating system input queue, which means it is not possible to e.g. use the action API to interact with the surrounding system or native widget controls. On the other hand, because the input is synthesised, it is possible to use WebDriver instructions to interact with hidden Firefox windows, and Firefox windows that are headless (using the |
|
Ok, I did add this other test to the my local marionette tests around the issue. def test_undo_via_element_sendkeys(self):
self.reporter_element.send_keys("abcdef" + Keys.CONTROL + "z" + Keys.CONTROL + "123456")
self.assertEqual(self.key_reporter_value, "123456")and also tested it via a code snippet using selenium java and it worked. So it seems is not a problem of the So far as I have seen this other problem is more specific and its a change of behavior inside Firefox. Maybe it is good to have a note or a list of all those combinations that doesn't work, or why some of them doesn't work. Or maybe a warning at some level that says that this chrome operations are not allowed, when they are triggered from a content context. |
|
I did compare the two cases:
and that generated this change in the logs during the sending of the CONTROL key combinations:
we have just an extra log line in the failing case during the sending of
Also the failing case include this extra line:
Does it means that at the moment of closing the browser there was an extra process running ? Might that is related with this Tab selection in multiprocess Firefox ? Multiprocess Firefox is something relatively new. |
|
More info: I have made a test disabling the multiprocess feature of Firefox and the So as long as I see this is not a problem from the geckodriver, although it would be good to know how are we supposed to open a new tab using geckodriver. In the meanwhile I am going to disable that feature for the tests that use new tabs, in the cases that I need that. But this seems not to be a geckodriver problem, so you might want to close the ticket. |
|
As we are aware on bug 380637 some websites override those shortcuts. There is still no appropriate fix for that available. If you want to open a new tab you can first load a HTML testcase like https://dxr.mozilla.org/mozilla-central/source/testing/marionette/harness/marionette_harness/www/windowHandles.html which can open a new tab by just clicking an element on the page. |
That's my point. But it was allowed until recent versions, as you can see in the forums. We did also use it, until we did decide to upgrade Firefox and Selenium. It did stop working then.
Ok, I can understand that we shouldn't use it anymore. That's why I was asking the right way to do it. Something confuses me here though: As long as I understand, the geckodriver is conceived to implement only the Webdriver standard, and not all the chrome features. But the standard covers some sections to handle windows, and that is supposed to be from chrome. Does it mean that more chrome functions can be added to the standard (like handling tabs) as long as it is needed and agreed by all the browsers ?
I don't see it neither. But it does. You can run the code that I submitted in my last comment and comment the lines where I disable the multiprocess stuff. As a matter of fact I did come to that conclusion because there was an extra log line when I send
This seems not to be the problem in this case. During the tests, I can click by myself in the tab, press
I would, but that doesn't work always. Depending on the setting of the browsers int can mean "open a new Window". And that's because there is a missing information in this spec: An additional problem is that the settings involved are frozen in the selenium profile, and for some reason they are set to open a new window in the last selenium. The implementation using Firefox options is not clear to me using the python binding. You can check more about it here: SeleniumHQ/selenium#2106 |
Yes, geckodriver implements the webdriver spec but on top of that each driver is allowed to specify custom commands. But those have to be put into a custom namespace. For us those commands end up at
That's because
Good point. If you could do the above check with older versions of Firefox I can help once we know what's going on.
I see. Maybe for now just tweak the preferences with
You can do this like: |
|
I'm seeing Actions.sendKeys(Keys.CONTROL + "C" + Keys.CONTROL) fail in FF56 + geckodriver v18 or v19 but succeed in LegacyMode in FF56 (Selenium v3.5.3). Can anyone else confirm this? (Sequence should do a copy.) |
|
If I created a new issue specifically about Keys.CONTROL + "C" + Keys.CONTROL not working, I suppose it would just be closed as a duplicate of this issue, because in the title at least, it's not specific, though it appears the OP was interested mainly in sending a CONTROL "T". However, I'm tempted to create a new issue because I can't understand how a major issue like this has been sitting idle for months This is an absolute showstopper for us as we can't move from Legacy mode without this working. Is it at least known whether this is an issue in geckodriver or in WebDriver? |
|
[Ctrl + T] is still an issue in Selenium 3.5.3, GeckoDriver 0.19, and Firefox 56.0.2. |
|
Control + T for opening a new tab, and generally any command that interacts with the chrome of Firefox, are explicitly not meant to work. |
|
@andreastt, the issue is that they use to work, and are very helpful for Selenium users. |
|
@BrandonDude WebDriver targets web content automation, and that interacts with Firefox UI, which is outside that realm. You need to switch to chrome context for key bindings to have any effect on the surrounding chrome. |
|
Our application uses Control-clicks to activate certain functionalities. This also does not work using the FireFox WebDriver. This does work using the Chrome WebDriver. Is there some information about switching to chrome context in Selenium? I cannot find anything using a naive google query. |
|
@GARMBoshouwers your information is very generic, and without telling us which kind of clicks you are using, we cannot help. Regarding the general issue for opening a new tab or window I just filed w3c/webdriver#1138, so we may be able to get a new command added to the webdriver specification. You may vote if you are interested in.
I cannot speak about bindings other then Python, but for the latter there is |
|
"Control + T for opening a new tab, and generally any command that interacts with the chrome of Firefox, are explicitly not meant to work." What about Control + C and Control + V (cut and paste) that I mentioned above? Are they meant to work? Is someone working on fixing them? That falls under the scope of this Issue as the title appears to be agnostic with respect to which keys are sent with the chord. I'm referring to FF56, but also note that in this (chrome-specific) issue, the dev told him to report the issue against chromedriver - should this issue be reported against geckodriver? (It works in legacy mode, and also used to work for Chrome in WebDriver v2). |
|
@gwtuser As I understand it, they are not intended to work either. |
|
Well it's disappointing that existing functionality that worked in WebDriver 2.x is now intentionally broken. It may mean WebDriver is a dead end for our customers. I suppose I can file a bug against geckodriver and see if that leads anywhere. |
|
It is my impression that allowing the driver to interact with the surrounding system, outside of the web content, is a big security risk considering that WebDriver is an RPC mechanism. |
|
OK, I think I may have a workaround that could help other users. The following sequences work in Legacy FF mode, but not under the new geckodriver-driven mode, where they seem to fail with no error message: However, the following works under the new geckodriver-driven mode: So, one way to get existing sequences like the top one I listed working under the new geckodriver-driven mode is to manually parse out modifier keys and execute them in the manner of the function composition form listed. This begs the question - if I can do it that way, then it not working the first two ways is not a security issue, so why was that use case broken in WebDriver 3.x? |
AFAIK those should work given that they operate in the content context. And as we have just seen it seems to work when control is pressed separately from the real key. I don't know about actions yet and would have to defer to @andreastt or @jgraham in how it is intended to work. |
|
@gwtuser Sequences like ^C ^V are meant to work in content scope (e.g. in a web form field) and they do. I just wrote some web-platform tests to confirm this. See https://bugzilla.mozilla.org/show_bug.cgi?id=1415694 It's possible that the issue you're encountering is a bug in the client. (e.g. something like #888) Feel free to open a new issue specific to your problem and post trace-level logs so we can see what payload is actually being processed by geckodriver/marionette. Key chords do work in geckodriver as far as I can tell, and this discussion covers too many different cases, so closing. |
|
Just for the record. Those who are looking for a workaround, deactivate the multiprocess feature of Firefox works for us. The behavior I did observe is that somehow a process for the new Tab is open, and maybe loaded but not shown in the user interface. Anyway, according to the previous discussion, sending a key combination to a document element in order to perform an action outside the document seems to be not intended anymore. |
|
We should not recommend people to disable the multi-process feature of Firefox. Keep in mind that all of the speed improvements as been made with Firefox 57 will become mood. Further this single process mode is no longer deeply tested, and several bugs could appear which then can make your tests fail. |
|
@whimboo FF57 |
|
@hheexx in that case it would be worth filing a bug with the performance team so that this could be investigated, and improved. |
|
@whimboo I was just noting that the cause could be there. If I disable that and the old behavior comes without issues, that means that it should be related. Of course, if you disable the new main feature of the new features you are testing another browser. But for many of us the interest is to test the business work-flow of our applications. Use it for stress tests or some other resource-demanding performance tests will be expensive. Although I guess that in this specific context many people could be trying to use the "new tabs" with that goal. Maybe opening N tabs to see how much the browser can stand. In that case you are right, they would be loosing their time because they are testing precisely what their are disabling. In our case we test concurrency updates over the records, as long as we don't get the ultimate solution we try to get the old tests working. Unfortunately we don't have the time resources to dig more into the problem, to provide you more context. But I give you the key: multiprocess. Maybe the problem is that the multiprocess firefox team did enhance the separations of concerns (content vs browsing context) in this new firefox rewrite. Then the standard and selenium need to evolve accordingly. In the mean while we try to keep our workflow tests running. |
|
Disabling multiprocessing in Firefox will not be testing the same browser that your users are using. Firefox ships with it enabled and there will in the future be features that will stop working when run in single-process mode. |
|
@whimboo I am not sure about that bug filling. Memory usage is collateral damage of multi process model. 2 processes must use more memory then 1. Also IPC has cost. e10s is faster in perceived performance for tipical web browsing usage but in my case of 10 instances of Firefox always open and pumping pages... single process makes sense to be faster. |
|
I think it's not the right place to have a debate about e10s. It's driving us away from the real issue as filed here. Given that there is nothing more to add and the issue is closed I will also close comments on this issue now. |
whimboo
changed the title
In order to help us efficiently investigate your issue, please provide the following information:
Platform and application details
Steps to reproduce
Reproducable testcase:
WebDriver.get( "https://www.google.com" );WebDriver.findElement( By.xpath( "/html/body" ) ).sendKeys( Keys.chord( Keys.CONTROL, "n" ) );A trace level log:
The text was updated successfully, but these errors were encountered: