I'd like to write a Cypress test to verify that pressing ctrl-z (or cmd on a Mac but ignoring that for now) in an <input> text undoes the previously-typed text. For example:
cy.get('input')
.type('abc')
.should('have.value', 'abc')
.type('{ctrl+z}')
.should('have.value', '');
However, the .type('{ctrl+z}') doesn't actually seem to trigger the undo. This surprised me because I was able to trigger a custom keydown EventListener with the same .type('{ctrl+z}').
I know Cypress doesn't support keyboard shortcuts for copying/pasting, and I'm wondering if I'm running up against a limitation here.
I get that it's usually unnecessary to check something like this, which is default browser behavior and should work. But in my case, I want to make sure that my global ctrl-z listener isn't preventing the default undo behavior from firing.
You can do it with cypress-real-events
cy.get("input").focus();
cy.realType("abc")
cy.get("input").should('have.value', 'abc') // passes
cy.realPress(["Control", "z"])
cy.get("input").should('have.value', '') // passes
Install with
npm install cypress-real-events
// or
yarn add cypress-real-events
Add an import to cypress/suport/e2e.js
import "cypress-real-events/support";
I have a pop up window containing a script in its head. And this script should be triggered by click on the window button. But after click on this button the script does not run. Could you suggest the reason?
Steps to reproduce:
Click on a button in the main window.
Child window containing a simple form is open.
Move to the child window, fill in the form fields and click on submit button.
Expected result: The click triggers a script located in the child window head. The script process the form and submit it.
Actual result: an error arises: "submitMyForm is not defined" (reference: submitMyForm() is a method containing in the script mentioned above).
So the problem is that the child window form fields can be populated and form button can be clicked but the script bounded to the button by means of the link <a href="javascript:submitMyForm();"> does not work as the function submitMyForm() is not found. Obviously the reason of the test failure is stubbing the child window which is performed to prevent having 2 windows at the same time. After this the child window is opening in the same browser tab as Cypress is not able to work with 2 windows open in the same time. But in this case the script stops working neither from the test nor by performing the click manually.
Here is a code snippet from the Cypress test:
const pop_url = `/dir1/dir2/file.php?id=${sectionId}`; // Here is a new window URL
cy.window().then( win => {
const stub = cy.stub(win, 'open').as('windowopen');
newSurveySectionListObj.AddNewBtnClick(); // Triggers form opening in the new window
cy.get('#windowopen').should('be.called.with', pop_url);
cy.window().then( $win => {
$win.location.href = pop_url
newSurveySectionListObj.typeDropdownSelect('Matrix'); // works fine
newSurveySectionListObj.modalDescriptionFldType('Cypress test string'); // works fine
newSurveySectionListObj.responseTypeDropdownSelect('Checkbox'); // works fine
cy.get('a[href="javascript:submitMyForm();"]').click(); // Does not work despite the button is clicked. An error "submitMyForm is // not defined" arises
});
});
You are going beyond what Cypress is capable of/designed for.
I would question why you are using a separate window in your app? You will run afoul of pop-up blockers that will prevent the new window being opened anyway. A percentage of users won't be able to work it out.
There are 2 approaches to this:
Use a modal dialog to achieve this (not great on mobile)
Use another route/page to display your form, return to the prev page when done
These have the advantage that they won't break with pop-up blockers, and your Cypress tests will work, as they are still in the same window.
I am writing a plugin that uses a dialog box.
I notice that clicking the toolbar button to open the dialog box fires a change event on the editor. Is there anyway to disable this event when opening the dialog box?
The plugin modifies the content using setAttribute(), removeAttribute(), and removeStyles(). Is there anyway to have calls to these methods fire a change event?
After more investigation, I discovered 2 issues (which I think relates to using YUI's App Framework), which might be the cause of the unexpected behaviour.
To reproduce: http://jsfiddle.net/c3tqk/
Problem 1:
1. Select part of the first paragraph (text) and click the Edit Link button.
2. Select part of the second paragraph (link) and click the Edit Link button. Check the console and notice a change event is fired.
Problem 2:
1. Select ex in the first paragraph and click the Bold button.
2. Deselect and select the x in the first paragraph and click the Bold button. Notice that the change event is fired twice.
You can always fire an event manually though it's not usually recommended. Use CKEDITOR.event.fire:
element.setAttribute( 'foo', 'bar' );
editor.fire( 'change' );
A better idea is to use editor#saveSnapshot event, which creates undo snapshots (your change becomes officially undoable, that's pretty cool) and fires editor#change automatically, if needed:
element.setAttribute( 'foo', 'bar' );
editor.fire( 'saveSnapshot' );
You can also interrupt existing events as they get fired and make sure no other listeners are called. Simply use CKEDITOR.event.on listener with low priority.
editor.on( 'change', function( evt ) {
if ( some condition ) {
evt.stop();
// ...or...
evt.cancel();
}
}, editor, null, -999 ); // by default listeners have priority=10
See CKEDITOR.eventInfo.stop and CKEDITOR.eventInfo.cancel. They're slightly different.
It might be tricky to get why the event is fired as you click to open the dialog box (and to create the right rule), but it feels quite possible. I couldn't reproduce it though (tried latest Chrome and FF); change was fired only when typing or executing commands (like Bold, Link, etc.). If you provided some extra info about your setup (versions of CKEditor and the browser, editor config and the name of the dialog), it would be much easier to debug.
I'm using Watir-webdriver and I was wondering if there was a good way to check if a new window opens. I've googled around a bit and couldn't find anything though it feels like there should be an easy answer.
I have a printer friendly link and I want to test that the link opens in a new window or tab and I would like to test this with ie, firefox, chrome and safari if possible.
Thanks!
You can check the number of windows:
browser.windows.size
or check if a specific window exists:
browser.window(:title => "foo").exists?
More examples in the specs.
You can also use index based browser window checking where you need to worry about index only and it follows zero based index ordering. So, the default window is of index: 0 and if a new window opens it will be of index: 1, the next will be of index: 2 and so on.
To check first child window if you want to test that the link opens in a new window ,
browser.window(index: 1).exists?
Or to work inside this window,
browser.window(index: 1).use do
# do scripting here
end
Sometimes I need to inspect elements that are only showing up on a page if you put mouse over some area. The problem is that if you start moving mouse towards firebug console in order to see the changes, mouse-out event is triggered and all changes I am trying to inspect disappear. How to deal with such cases?
Basically I am looking for something that would either:
Switch to firebug console without moving a mouse (using keyboard shortcuts maybe? But I can't figure out how to use firebug with keyboard only)
Have an ability to "freeze" the page so your mouse movements don't trigger any events anymore.
Thanks.
HTML Tooltip (Firebug)
Select the element with the inspector or in the DOM. Go to the "Styles" tab in firebug and click to the small arrow on the tab and select ":hover" (also available ":active"). The state will remain on "hover" and you can select other elements to make them hover.
HTML Tooltip (Firefox developer tools)
Click the button to see three checkboxes, which you can use to set the :hover, :active and :focus pseudo-classes for the selected element
This feature can also be accessed from the popup menu in the HTML view.
If you set one of these pseudo-classes for a node, an orange dot appears in the markup view next to all nodes to which the pseudo-class has been applied:
JQuery Tooltip
Open the console and enter jQuery('.css-class').trigger('mouseover')
Regular Javascript Tooltip
Open the console and enter document.getElementById('yourId').dispatchEvent(new Event('mouseover'));
The style panel in Firebug has a dropdown menu where you can choose the :active or :hover state.
You can also start the debugger on a timer. Enter this command into the console:
setTimeout(function(){ debugger; }, 10000);
This will give you 10 seconds to use the mouse and make the page look the way you want in order to inspect it. When the debugger starts, the page will freeze, and you'll be able to explore the elements in the developer tool tab, without the DOM changing or responding to any additional mouse events.
I think you can also do this :
Choose Firebugs Inspect mode
Hover over the item that pops up the element you wish to inspect and then use the Tab key several times to make Firebug active (I found it tricky to see when Firebug was the active component but nothing like trial and error - when I saw that Firefoxes Find Toolbar was active I'd then Shift + Tab backwards twice to get into Firebug.
Then I'd use the L/R arrow keys to contract/expand elements and U/D arrow keys to navigate through Firebugs console
Worked for me anyway!
For Jquery UI tooltip I finally set up a long delay for the hiding of the element so I have time to inspect it before it's deleted. For example, I used this to inspect the tooltip:
$( document ).tooltip({ hide: {duration: 100000 } });
instead of:
$( document ).tooltip();
You could insert a breakpoint at the start of the mouseout event handler. Its code won't be executed until you allow it to continue, and you can use the DOM inspector and so forth while execution is stopped.
Firebug's hotkey for inspecting elements is Ctrl + Shift + C (Windows/Linux).
Go here for a list of all Firebug keyboard shortcuts.
For the bootstrap tooltip:
$(document ).tooltip({delay: { show: 0, hide: 100000 }});
While selecting :hover in the CSS menu might be nice if you only want to inspect some CSS code, it doesn't work if whatever you want to inspect is changed using JavaScript.
A simple hack in this case is to open Firebug in a different window (top right corner of the Firebug bar) than move your mouse at the desired location and drag and drop something from there out of the browser window. Now you can inspect whatever in the Firebug window. Just don't move your mouse back into the browser window.
For Javascript events such as Mouse over.
Open Firebug/Inspect an element.
Click on the element before the mouseover event, e.g. click on a div. It will turn blue to show it is selected.
Put your mouse over the element and don't move it from this point forward.
Use your ↑/↓ arrow keys to manoeuvre in Firebug.
Use your ←/→ arrow keys to expand/contract code with + or -.
Double tap Tab to get to the CSS pane.
Use the arrow keys to navigate. Use shift and arrow keys to select text. Ctrl & C to copy.
Hold Shift and double tap Tab to get back to the HTML pane.
I'd like to chip in with my preferred method. Putting this little snippet in your console allows you to start the debugger at any time with a simple keypress on your keyboard (F8 is used in this example)
document.addEventListener("keydown", (event) => {if (event.key == 'F8') {debugger}});
You can also use a keycode if you prefer:
document.addEventListener("keydown", (event) => {if (event.keyCode == 119) {debugger}});
I found that Chrome does work a bit differently than Firefox. In particular, menus that close when the mouse is clicked outside of the menu remain open when inspecting them in Chrome (and they close when inspecting them with Firebug). So the advice is to try to use a different development tool in a different browser to see if it makes a difference.
Open console:
If you have javascript based tooltip, find applicable elements in console with appropriate selector. like below and confirm you able to find appropriate element with selectors.
$('your selector')
Write above javascript and Press enter. you will have list of elements.
Now e.g. If library added event on mouseenter enter following script:
$('your selector').mouseenter()
Press enter.
This way you can simulate mouse movement events without actual mouse. and can use actual mouse pointer to investigate thing in debugger tool.
This is an extremely old question by now, but I've found an answer that directly answers the "freeze the browser" portion of the question.
Control + Alt + B. This is "break on mutate". Which means, when you are hovering over an element with firebug engaged (Control + Shift + C), that when the HTML attributes would change, instead they hit a breakpoint, allowing you to easily navigate around to examine for paths, etc.