I have an HTA interface that I'm working on. When I click a button I want a sound to be played each time that I click that button, without looping, and it does it just fine at first, but shortly after it doesn't play the sound anymore when I click the button, even after restarting the application, and it won't play again until after I restart my computer.
Here is the general layout of the function I call:
function playSound() {
var mySound= new Audio('Sounds/mySound.mp3');
mySound.loop = false;
mySound.play();
};
Any ideas?
PS. this is my first post, so please let me know if I should change anything about this post.
Related
Update:
After further investigation, actually what's happening is when the checkbox is checked using jquery, the next step is to click the button to save. Well, for some unknown reason, the checkbox is unchecking itself.
Here's the jquery to select the checkbox:
string jsStmt = #"
$(function(){
$(':checkbox').filter(function(){
return $(this).parent().next('td').text() === 'Label to look for';
}).prop('checked', true);
});
";
IJavaScriptExecutor js = (IJavaScriptExecutor)_driver;
js.ExecuteScript(jsStmt);
I can see the checkbox get checked, then when the dialog closes I can see it get unchecked?
OP:
Button click event for Selenium testing has been working for a while. All of a sudden, it's not working anymore. Only possible change was some 3rd party css change but I don't know what it could've been.
The button is kind of buried in layers, however, there's a checkbox that gets checked by Selenium that is still working fine, and it's the reason why the button needs to be clicked.
I can debug, and see that Selenium is finding the button. It appears that the button gets clicked but the postback event doesn't occur.
I can stop execution right before the click event and open developer tools and manually type in the statement to click the button, AND that works!
I even tried executing the click with JavaScriptExecutor with no luck.
I am so lost why it's Not firing postback event.
In short, try clicking the checkbox using an IWebElement instead of javascript.
I would suggest avoiding using IJavaScriptExecutor as much as possible in selenium tests as it can lead to performing functions the user wouldn't actually be able to do with simple interactions, or having those functions behave differently than you would expect because the execution path is different than what a user would do if they just clicked something.
I think that's what you're running to in this case where you're trying to mark the box as checked.
How to simulate the cancel button pressing for QFileDialog?
Searching doesn't help much here as most threads (like this one) are talking about simulating key pressing for QT application, not particularly for a QFileDialog.
P.S.: I want to do this because currently I am using a library created by others, the code somehow depend on the QFileDialog to open. It is becoming very annoying if needing user intersection each time by manually pressing the cancel button.
Any help is appreciated.
I assume the library uses QFileDialog as shown in the documentation:
QFileDialog dialog(this);
dialog.setFileMode(QFileDialog::AnyFile);
QStringList fileNames;
if (dialog.exec()) {
fileNames = dialog.selectedFiles();
}
In that case you can just hide it. It causes exec() to return QDialog::Rejected immediately:
fileDialog->hide();
Something seems to have changed in Qt 5: you can't get a drop or move event if you don't move at least one pixel from the start point where you were when QDrag::exec() was called. Try putting a breakpoint in the dropEvent of the Draggable Icons Sample, then click a boat and release it without moving the mouse. That generates an "ignore" without any drop signal.
(This is on Kubuntu 13.10 with Qt 5.1.)
When teaching how to start a drag operation, the documentation suggests you might use manhattanDistance() to determine if the mouse has moved enough to really qualify as "the user intending to start a drag". But you don't have to use that; you can start up a QDrag on the click itself.
Anyone know of a workaround to have that same kind of choice on the drop side, or is that choice gone completely? :-/
Why I care: I've long had frustrations trying to get a tight control on mouse behavior in GUI apps—Qt included. There seems to be no trustworthy state transition diagram you can draw of the invariants. It's a house of cards you can disprove very easily with simple tests like:
virtual void enterEvent(QEvent * event) {
Q_ASSERT(!_entered);
_entered = true;
}
virtual void leaveEvent(QEvent * event) {
Q_ASSERT(_entered);
_entered = false;
}
This breaks all kinds of ways, and how it breaks depends on the platform. (For the moment I'll talk about Kubuntu 13.10 with Qt 5.1.) If you press the mouse button and drag out of the widget, you'll receive a leaveEvent when you cross the boundary...and then another leaveEvent when the button is released. If you leave the window and activate another app in a window on screen and then click inside the widget to reactivate the Qt app, you'll get two consecutive enterEvents.
Repeat this pattern for every mouse event, and try and get a solid hold on the invariants...good luck! Nailing these down into a bulletproof app that "knows" it's state and doesn't fall apart (especially in the face of wild clicking and alt-Tabbing) is a bit of a lost cause.
This isn't good if your program does allocations and has heavy processing, and doesn't want to do a lot of sweeping under the rug (e.g. "Oh, I was doing some processing in response to being entered... but I just got entered again without a leave. Hm, I guess that happens! Throw the current calculations away and start again...")
In the past what I've done is to handle all my mouse operations (even simple clicking) with drag & drop. Getting the OS drag & drop facility involved in the operation tended to produce a more robust experience. I can only presume this is because the testers actually had to consider things like task switching with alt-Tab, etc. and not cause multiple drop operations or just forget that an operation had been started.
But the "baked in at a level deeper than the framework" aspect actually makes this one-pixel-move requirement impossible to change. I tried to hack around it by setting a timer event, then faking a QMouseEvent to bump the cursor to a new position once the drag was in effect. However, I surmise that the drag and drop is hooked in at the platform level, and doesn't consult the ordinary Qt event queue: src/plugins/platforms/xcb/qxcbdrag.cpp
The issue has--as of 1-May-2014--been acknowledged as a bug by the Qt team:
https://bugreports.qt-project.org/browse/QTBUG-34331
It seems that me bountying it here finally brought it to their attention, though it did not generate any SO answers I could accept to finalize the issue. So I'm writing and accepting my own. Good work, me. (?) Sorry for not having a better answer. :-/
There is another unfortunate side effect of the Qt5 change, pointed out by a "Dmitry Mordvinov":
Same problem here. Additionally app events are not handled till the first mouse event after drag started and this is really nasty bug. For example all app animations are suspended during that moment or application hangs up when you try to drag with touch monitor.
#dvvrd had to work around it, but felt the workaround was too ugly to share. So it seems that if you're affected by the problem, the right thing to do is go weigh in...and add your voice to the issue tracker to perhaps raise the priority of a solution.
(Or even better: patch it and submit the patch. 'tis open source, after all...)
i want to open a popup window when user leaves tab or closes browser, the available option with me was window.open, but with that, it asks for popup blocker, if it is not enabled, i tried every possible ways to ignore popup-blocker but in vain, i tried onunload, onbeforeunload, but it does not works, i also tried to use modal dialog, before the tab/browser, i used it in onbeforeunload event, but it shows a browsers alert message, which i dont want, my simple requirement is, i need a popup window (if possible) or modal dialog, on the close of tab/browser, but should ignore popup-blocker, i guess with modal dialog, i dont need to worry about popup-blocker, because that wont be the new window, but how i would be handling it, while user closes tab/browser. If any of the above option is not possible, can anyone help me with any other possible alternative, or helpful articles.
Edited Question
i used the below script and with that i can open a new popup window on link click, without popup-blocker interfering in it
$('a[href=http://www.google.com]').click(function(){
window.open(this.href);
return false;
});
then why its not possible for the closing events.
You can't - because that's what popup blockers do: they block popup windows (i.e. calls to window.open or invocations of target="_blank" links) unless it is directly in response to a user mouse action.
Opening popups when a browser window is closed was a common tactic of "pop-under" ads in the early 2000s, and it irritated users, that's why Firefox and IE6's popup blocker block them, and there is no way around it for you unless you ask the user to disable their popup blocker on your site (and I think you'll find most of them will have no idea how to do that).
What are you trying to accomplish anyway? What is the content of this popup that you want the user to see? What other approaches have you tried?
Exact duplicate of your previous question....
I'll post my answer for it here as well though...
Popup blockers are designed to prevent this behavior.
I would suggest using a modal window instead of an actual browser window. I don't think that these get blocked because they are opened within the page itself.
As for the event... You could do something like...
window.onbeforeunload = function whatever() {
//Do code here for your modal to show up.
}
If you are just trying ot give a warning or something you could do
window.onbeforeunload = function showWarning() {
returnString = 'Whatever you want your message to be....';
return returnString;
}
By returning something in the onbeforeunload statement it will show a confirm box with your message in it.
Popup blocker will not block the opening of popups if the javascript code which opens the popup is executed on user's direct action like click, keypress, drag, etc.
I have attached some javascript on onload event of the form. this script contains window.open. Although this works fine in all the browsers window.open doesn't open a new window nor it gives nay error message in google chrome and firefox.
I want to first check the screen resolution if it is less than 1024 then I would open it in a new window without menu,toolbar and others so that the user has more space to work on.
This is a feature, not a bug! :)
remember back in the '90s when pop-up windows annoyed the crap out of everyone? Well, because of the MASSIVE abuse of that JavaScript behavior, now the only way to open windows is with direct user interaction; like a click.
If you have a legitimate reason for opening another window, attach a click event to a button labeled such that it properly indicates you'll be opening a window. If your user wants to open the window, they will do so, and it will correctly get past any but the stupidest popup blockers. If they don't want to, you should not be opening a window in the first place.