When I write
b.windows.last.use do
b.link.click
end
Once after the click, WATIR automatically switch back to first window, now I can start operating on first window, but I don't know how to close this child window and start operating on first window. I could do it in selenium but I don't know how to do it in WATIR.
What I have tried
require 'watir'
driver = Selenium::WebDriver.for :firefox
b = Watir::Browser.new driver
b.goto("https://www.w3schools.com/jsref/tryit.asp?filename=tryjsref_win_open")
b.iframe(id: 'iframeResult').element(xpath: "//button[contains(text(),'Try it')]").click
firstWindow=b.windows.first
b.windows.last.use do
b.element(text: 'LEARN HTML').click
end #end of this block automatically switch back to first window.
b.windows.last.close #Closing the child window
#b.iframe(id: 'iframeResult').element(xpath: "//button[contains(text(),'Try it')]").click
#This above line is not working so made a switch in the following line
firstWindow.use do #but it's not working as expected too.
b.iframe(id: 'iframeResult').element(xpath: "//button[contains(text(),'Try it')]").click
end
WATIR allows me to operate on the parent window through automatic switch but if I close the child window after this automatic switch, I don't have any way to connect back to the parent window even though automatic switch was done or connection to the parent window lost.
Ah, looks like a performance enhancement we made resulted in a bug collision with Firefox - https://github.com/mozilla/geckodriver/issues/610
First, I personally avoid using blocks when working with windows, so my code would look like this:
b.window(url: 'https://www.w3schools.com/').use
# do things
b.window.close
b.original_window.use
The problem is that because the element that opened the second window was inside an iframe, when Watir switches back to the first window, Firefox keeps the browsing context in the iframe instead of restoring it to the top level context. Watir used to always reset it with every element lookup, but those were extra wire calls, so we cached the context and now only make the call to switch to the top when necessary.
The temporary workaround until Mozilla fixes that bug is to do:
b.wd.switch_to.default_content
Related
I created a single-window menu scheme using ncurses and got it working.
When I added a second window, I can no longer get my wgetch call to fire (or so it seems).
Somewhat confusing to me is the function prototype :
int wgetch(WINDOW *win);
which says wgetch somehow depends on the window but I don't get the relationship - how does "the window" matter? If it does, and I have more than one window, which one do I use? Also, https://linux.die.net/man/3/wgetch says "There is just one input queue for all windows." which tells me "the window" is a "don't care".
Can someone explain?
Thanks.
The window matters because wgetch refreshes the window before reading characters. That's in the wgetch manual page:
If the window is not a pad, and it has been moved or modified since the
last call to wrefresh, wrefresh will be called before another character
is read.
Each window (including stdscr) may have been altered since the last call to wrefresh. If you make changes in one window without refreshing it, and then call wgetch in another window, the changes to the first window are not automatically displayed. You can use wnoutrefresh to combine refreshes, e.g., using that for the first window and then use the wrefresh done automatically for the second window to refresh both.
I write automated tests for a website. One of the tests needs to press Ctrl+S and type some letters to save a webpage including CSS/JS. The test should require Firefox to have window focus for those several seconds to be able to type the filename and click "Save" (currently XDoTool is used for pressing keys and clicking the mouse).
Sometimes I run the tests on my computer. I don't want to occasionally type something or change the window focus while the page is being saved, so I want to prohibit changing focus for those several seconds when those mouse clicks/key presses are running.
It's not possible to do it at the Webdriver level (a tool that I use for controlling the browser), so I think I should do it at the OS level. Can I prohibit the user from changing window focus or typing anything for a period of time? It may look like:
prohibit user from typing keys/change window focus
save page
allow user to type/change window focus
I guess that another way to achieve the desired effect would be to run Firefox and your automated tests on a nested X server (xf86-video-nested/Xephyr/Xnest).
$ Xnest :1
$ export DISPLAY=:1.0
$ firefox http://something/to/test &
$ your-test-script
Since the nested X server has it's own idea of the focused window, moving the focus on your desktop shouldn't affect it.
(If you don't actually need to see the test progressing, you could use a dummy X server (xf86-video-dummy/Xvfb/Xfake) instead)
I'm trying to use the ocaml graphics module.
The line:
#Graphics.open_graph "";;
works fine in the interactive module, i.e. a small window pop up in X11 with white background.
However, when I try to use the script mode -- put this line in a file then compile it:
ocamlc -o a.out graphics.cma code.ml
only X11 starts but with no window popup.
Am using a mac. Anyone knows why? Thanks.
Followup:
It seems under script mode the popup window will closeup immediately after code execution. Because if I compile using XTerminal, I can see a small window popup but then closes.
I managed to keep the window open by adding an infinit loop at the bottom:
while true do () done;;
But still don't understand how things really work. Please help. Thanks.
All ressources are freed when the script terminates: memory, file descriptors, including the X window.
If you add an infinite loop, the script does not terminates, and the windows stays open.
Likewise, under the toplevel, the window stays open as long as you don't close the toplevel.
I would suggest to add two lines add the end of your script:
print "press enter to exit"
read one line from keyboard input
This way the script will not terminate until the user presses enter.
Indeed, as jrouquie explains you need to delay the termination of your program. The way I personally do that is by waiting on user input. At the end of the interactive program (or function being studied that opens the graphic mode), I put:
ignore (Graphics.read_key ())
This will wait until a key has been hit on the keyboard, and ignore the key value before returning.
I'm working on a I/O verification tool based on Linux in a game project. It is written in C++, and,since using the same I/O module as our game, it's based on OIS 1.2. Thus, though all I need is to print users' inputs on the console, I still need to create a window for OIS.
So here comes my question: How can I create a mapped window while it is still invisible and processes keyboard events?
I can't unmapped the window in that it won't process any keyboard event anymore. I also can't find function for show/hide a window.(maybe I search through a wrong diretion...)
My little tool works fine now except there is a stupid top-level empty window which needs to be focused for processing keyboard events...
Any advise is welcomed.
Thanks!!!
After reading this post: Linux/X11 input library without creating a window,
I realized my problem was that I misunderstood the philosophy of X11. All I need to do is simply pass the root window handle to OIS, and set the x11_grabkeyboard flag as true. The only drawback is maybe I can hardly debug my program with gdb since the keyboard is grabbed...
Though my situation is solved, there is one thing left.
Every article I read said an InputOnly window won't be visible and is capable for handling input events, while my InputOnly window is absolutely visible after mapped...
Maybe it's my Linux, or again, a misunderstanding...
I have an application that sends the focus to other windows but those windows then don't automatically display themselves in the foreground, i.e. on top of all the other windows. Where can I configure the preferences of my window manager so that this is the default behaviour?
In particular I'm using the Ctrl-0 and Ctrl-Shft-0 shortcuts in the MATLAB IDE to move between the command window and the editor window and although the focus seems to be transferred the new window doesn't automatically redraw itself in the foreground.
Not sure of a key binding off hand that does it, but if you alt-click on a window (which allows you to drag a window) it should come to the front.
As codeDr suggests, MATLAB is also kind of bad about repainting its windows. If you draw to a figure while code is executing, the figure does not update unless you execute drawnow or have some similar pause in the execution to allow the GUI to repaint. Since we're talking about MATLAB, the figure command will also cause the indicated figure to come to the front (in fact, it's harder to get it to not come to the front). So you could do figure(gcf) to bring the current figure to the front, or save the figure number with h = figure; and then later do figure(h). Incidentally, if you want to switch current figures without switching focus, set(0, 'CurrentFigure', h) should set h to the current figure.
Your window manager (probably Metacity?) implements focus-stealing prevention so that rogue apps don't pop up windows that would disturb your typing. Matlab needs to raise its window, and give it the input focus with the correct timestamp. If this is being done from a KeyPress event handler, the timestamp for setting the input focus would be the timestamp from the KeyPress event (i.e. the timestamp of the user-generated event that caused a window to be raised/focused).
To politely give the input focus to a window, google for _NET_ACTIVE_WINDOW.
Usually when the window doesn't repaint, it means that the application's main application loop isn't running to refresh the window. Could it be that Matlab is doing some computation or disk activity when you are switching between windows?