Check the test page here http://rickchristie.com/testfocus.html
Correct me if I'm wrong:
onfocus happens when the element gains focus.
onblur happens when the element loses the focus.
In Firefox 3.6.12 (tested on mac and windows), using onblur without onfocus works fine. However when an input element has both onfocus and onblur element, it gets weird:
When you click at the input, onblur is fired instead of onfocus.
Right after onblur, onfocus fires immediately.
You can't type anything in the textbox.
Other browsers (Safari, Opera) works as expected. Is this a bug? Is it just me or is everybody using Firefox experiencing this?
Update
This behavior seems to happen only when onblur and onfocus contains alert - not when I use something like window.log.
When the alert box opens, focus is removed from the text box. Notice that the "BLUR" alert box opens right on top of the "FOCUS" alert box (the latter opened first), so that's why it looks like onblur fired before onfocus.
Look at my test page, which increments a counter when either event handler is called and also adds a second alert box after both of the others. It seems that Firefox actually starts executing the blur handler as soon as the alert box from the focus handler opens, despite the conceptually single-threaded model of the browser. However, when the first (focus) alert box is closed, the second (blur) alert box has to also be closed before the third (after focus) alert box opens.
I don't know Firefox why does it the way it does. Chrome keeps firing the focus handler again and again, and Opera, Safari, and IE do it the way you would expect — not taking away the text box's focus.
EDIT: I've found https://bugzilla.mozilla.org/show_bug.cgi?id=31889 and will be posting this test case there – apparently it used to be even worse.
Related
Context: In my rspec (using Ruby and Capybara)
I click on a link to test an action in my app: adding a branch to my app.
A modal window opens, where I select the branch, and then I click a "submit" button to add the branch to my app. After clicking "submit" the modal window is closed.
The rspecs continues by clicking "Save" in the main screen, to save the state of the application (and effectively saving adding the branch).
Problem: The rspec is failing because (seemingly) it is trying to click the "Save" button on the main screen while the modal window that is used to select the branch is still present. The test doesn't complain that it can't find the "Save" button component, but that it can't be clicked.
The error in the log is:
[...]Save</button> is not clickable at point (692, 23). Other element would receive the click[...]
A gotcha: this rspec passes correctly on some environments, like when it is run against my local server, but it fails when it is executed by our automation server. Thus, this test has been tagged as "flaky".
Potential solutions: Things we have tried so far:
Play around our "clicks configuration", making sure we are on "ready state" and that the modal window is gone. We failed with this, since we kept hitting the same error.
Implement a "wait". We added a loop to sleep for a bit while the modal window seemed to exist
XYZ.add_new_branch_name(#branch_name)
while Utilities.element_visible?(:xpath, myElement)
sleep(0.5)
end
XYZ.save
The while condition checks if the "submit" button of the modal window exists. The element_visible function uses
find(method,element).visible?
but I'm not sure if find should already take into account that the button may exist and be visible but not be clickable.
Since this still fails, in spite of all our effort to make sure that the modal is gone before we attempt to click on the "save" button, I want tot ask:
Is there a proper way to detect if an element behind a modal window is clickable or not using rspecs?
find only cares about "visibility", not "clickability" (and different drivers may have slightly different interpretations of "visibility"). The reason for the flakiness you're seeing is most likely speed of the machine running the tests which affects the timing of the modal animating away. The best way to solve this issue is to disable animations in the test mode (how you do that is dependent on exactly what library and/or CSS you're using for the animations). The other way is to do as you're doing - checking that the modal has disappeared before clicking the 'Save' button, however you should just be using the Capybara provided methods (which include waiting/retrying behavior) rather than writing your own loop for that.
expect(page).not_to have_css('css selector of the modal') # RSpec version
assert_no_css('css selector of the modal') # minitest version
After looking at the mouse position from your error, one other potential issue you may be having is with screen size and scrolling. If the page requires to be scrolled to get to the 'Save' button and (692, 23) would put the button behind a fixed header (you should be able to verify that by taking a screenshot before the button click attempt) then it may not be possible for whatever driver you're using to click the button. In that case you'd need to use execute_script to scroll the page to a different location so the button is not covered on the page and/or increase the "browser" size so scrolling isn't necessary in the test.
I had a similar problem and solved it by writing my own click_on_with_wait helper function:
def click_on_with_wait(text, wait_time: Capybara.default_max_wait_time)
success = false
(wait_time * 10).round.times do
click_on text
success = true
break
rescue Selenium::WebDriver::Error::WebDriverError
sleep(0.1)
end
# Try clicking one last time, so that the error will get raised if it still doesn't work
click_on text unless success
end
This will try to click on the element. If it's still hidden by the modal, the function will wait 100ms and then try again, until the given wait_time is reached.
Using Rails, I put it in system_spec_helpers.rb so that I can simply replace click_on 'Submit Form' with click_on_with_wait 'Submit Form'.
I have a paper-button with the on-tap function that opens a paper-dialog that contains a "Accept" paper-button that will close it when clicked.
The problem i'm getting is if depending on my screen resolution, and the dialog's "Accept" button is over the initial button to open the dialog, when clicked, the dialog opens and closes. I'm assuming the on-tap event is being fired to both.
I've tried these 2 methods but they do not seem to help.
event.cancelBubble = true;
event.stopPropagation();
The problem is that a capacitive screens or even mouses can generate multiple tap event on the same spot within a few milisec.
The mouses because a quick change in a high and low voltage (logical 1 and 0) generating an AC signal wich can jump trough on a capacitator (which can be the button two contactor between the air) if the conditions matching. But the onclick event is already catching this case and you does not require to do anything to solve it.
The capacitve screens are capacitators and just rolling your finger should trigger multiple tap events because your skin has different depth of insulation and hard to mark the tap begin and end in some cases.
This physical problem should be solved by the platform, but it is not in every situation currently (but most of the devices are filtering this). Im usally solving this isse with a transparent overlay element wich can catch the pointer events for a little duration so I could catch the "prelling" of a button or the capacitive screen for a few ms.
If a 10-20ms is enough for you then wait a frame in your on-tap function with requestAnimationFrame and then show the dialog. Cheap trick, but it does what it has to, but ultimately you can wait a fix timeout to show the dialog, because you have 100ms to respond a user interaction.
You cannot fix this by manipulating the browser events options though because as I know you dont have option to how much time need to pass until the next same event should happend. But if you wait a frame thats could behave like you add a delay between the events.
I have a semi-transparent form (using AlphaBlend) that acts as an overlay. For the user to still be able to interact with the window below I have set WS_EX_NOACTIVATE on my form so all right and left clicks go through to the other window.
However I have a few clickable labels on my form. Clicking those and performing the appropriate action works fine since despite the WS_EX_NOACTIVATE flag the OnClick methods are called, but the click will (obviousely) also propagate to the other window, which I do not want in this case.
So, does anyone know how to "stop" the click being sent through to the window below in case I already handled it in my form ? Basically I would like being able to chose whether the click "belongs to me" and does not get propagated or whether the window below mine receives it.
As Rob explained, WS_EX_NOACTIVATE is not relevant here. Most likely you used WS_EX_TRANSPARENT and that made your window transparent to mouse clicks.
To get finer grained control of mouse click transparency, handle the WM_NCHITTEST message in your top level window. Return HTTRANSPARENT for regions that you want to be "click through". Otherwise return, for example, HTCLIENT.
Wm_ex_NoActivate should be irrelevant here. That just controls whether your window receives the input focus. Indeed, if you start with a scratch program and do nothing but change the extended window style, you'll see that when you click within the bounds of that program's window, the clicks are handled in the usual way, except that the window is never activated; programs behind that window do not receive any click events.
Therefore, to make your label controls eat click events instead of forwarding them to the windows behind them, you need to find out what you did to make them start forwarding those messages and simply stop doing that, whatever that is.
I've seen plenty of information about this topic, but not the answer to this question exactly. I have the opposite problem of most. I want to prevent the Enter button from clicking a button when the button has focus. And to do this, I don't want to simply disable the button from accepting an Enter button press, but rather I want to conditionally capture the Enter button press in a callback method. Right now, I have bound the following event to all widgets in my python program:
parent.Bind(wx.EVT_CHAR, self.CharInputCallback)
The EVT_CHAR event is actually thrown when the enter button is pressed and I'm able to get the callback in my callback method. My problem is that the enter button's functionality of virtually clicking a button still goes through, despite purposely not skipping the event (which would forward on the event). Since this is happening, and I'm sure my callback method is not forwarding the event along (I've tested this by capturing characters going to a text box) I suspect that the enter button throws an additional event that I'm not capturing. I've tried binding and capturing the additional following events to prevent the "virtual click" from the enter button:
parent.Bind(wx.EVT_TEXT_ENTER, self.CharInputCallback)
parent.Bind(wx.EVT_KEY_UP, self.CharInputCallback)
parent.Bind(wx.EVT_KEY_DOWN, self.CharInputCallback)
Yet when I press enter, the button in focus is still clicked. To summarize, is there an additional event being thrown when I press the enter button? If so, which event in particular is "virtually clicking" the button? Most forums I've found have discussed how to recognize when the enter button is pressed, but I want to recognize it and disable it's default action when a button is in focus.
I tried binding all those events to different handlers and I also bound EVT_BUTTON. It appears that EVT_BUTTON always fires BEFORE the key and char events do. If you don't want your button to be clicked, then you'll probably have to either disable it, use a different widget (maybe one of the generic buttons) or create your own. I would also ask on the wxPython mailing list to see if they have any suggestions.
The only way to order the events in wxPython that I'm aware of is to use wx.CallAfter or wx.CallLater. I'm not sure how you'd use that in this context though.
The event that causes enter to click a button is the key up event. My code for my callback was messed up slightly. Capturing the key up event and not skipping it prevent the enter button from clicking a button in focus. On Windows 7 anyways.
I have an image element, following is the html for the button
<input type="image"src="images/undo.png" onmouseover="this.src='images/undo-hover.png'" onmouseout="this.src='images/undo.png'" id="btn_back" onClick="back();" >
When my application makes this input disabled (attribute disabled="disabled") all browsers stop firing mouse events. So I don't get hover images. But opera still keeps firing these event, and I keep getting the hover images on disabled elements.
Can you please try making the INPUT element disabled by default (add disabled="disabled" in the INPUT tag from start). Then see if Opera is still responding to mouse hover. This may not fix the issue right away but will help in figuring out the cause.
Also, another approach could be to call the JS function on mouse event and check if the element is disabled or not. If it is disabled then dont change the src attribute.
HTH,
this is a bug in Opera as we're apparently doing something different than other browsers. Please report it on https://bugs.opera.com/wizard/ and give me the bug ID.
That said, I don't think what you are relying on is standardised anywhere, so possibly you should not write code that depends on this somewhat quirky behaviour. The "disabled" attribute merely means that the element will not do its normal action when clicked. I don't really see any reason why setting disabled should prevent firing mouseover/move. It's easy to check from JS if the button is disabled and not swap the image if it is.
It seems like an expected behavior in opera, Please see the following link.
http://www.quirksmode.org/dom/events/click.html
It says that "A click event on a disabled form field does not fire events in Firefox and Safari. Opera fires the mousedown and mouseup events, but not the click event. IE fires mousedown and mouseup, but not click, on the form. All these implementations are considered correct."
Thanks,
Unnikrishnan B.