I am trying to assert that, when I mouseover a covered element, the element on top is activated and not the hidden one.
However, when using .trigger('mouseover') on the hidden object, an error occurs because I cannot mouseover that object, and the test stops.
Is there a way to try to mouseover and assert that a failure occurs?
Your best bet for now is probably to use this .shouldNotBeClickable() command, because if the element cannot be clicked then it also cannot be hovered. Use this command with caution, as it skips all remaining commands in your it() block when used due to a bug in Cypress.
As of right now (Cypress 3.1.0), this is not possible. It should be as per this answer, but cy.once() has some code-breaking bugs that I've run into trying to adapt the command in that answer.
The following custom command does not work as of Cypress 3.1.0. It should work, but it causes Cypress to hang.
index.js:
Cypress.Commands.add("shouldNotBeHoverable", {
prevSubject: true
}, function(subject) {
let errorMessage = "shouldNotBeHoverable: element hover succeeded, but it souldn't have";
let done = false;
cy.wrap(subject[0]).trigger('mouseover', { force: true });
cy.once('fail', (err) => {
if (err == errorMessage)
throw errorMessage;
expect(err.message).to.include('cy.trigger() failed because this element');
expect(err.message).to.include('is being covered by another element');
done = true;
});
cy.wrap(subject[0]).trigger('mouseover', {timeout: 1000});
cy.get('html').then(() => {
if (!done)
throw errorMessage;
});
});
Cypress test:
cy.get("#selector").shouldNotBeHoverable();
The related Github issues are linked below. This specific issue isn't reported, but both issues are similar enough that I suspect the underlying cause is the same.
Mixing cy.on()/cy.once() with a one-argument it() function causes test to hang
Queued commands silently skipped when using cy.once() in a custom command
Related
I have a script that asks for the user input to download (or not) a file. It's fairly straight forward, but I have a problem with the following piece of code. If the user chooses "NO", then the else if condition works fine and the code finishes its expected execuetion. But if the user chooses Yes, the file gets downloaded but I get the following error:
UnhandledPromiseRejectionWarning: TypeError: Promise resolver [object Array] is not a function
I problably need to learn more about Promises, but I share the section of the code that fails in case I am making an obvious mistake that I fail to see.
async function download_fallo(page) {
if (download == "Y") {
await new Promise([
page.click('div > div.col-xs-12.col-sm-11 > div.row > div.col-sm-4.col-lg-3 > a'),
//page.wait({ waitUntil: 'networkidle0' }) // does not work either
//page.wait(2000) // UnhandledPromiseRejectionWarning page.wait is not a function...
]);
return console.log("Perfect")
} else if (download == "N") {
console.log("Just the information then!") }
}
Thanks guys --- I was making obvious mistakes and you clarified them. I was not using Promise.all and made a mistake with page.await, both were pointed out. With that corrected, the code works. I post below in case someone finds it useful, it's a simple if condition tied to a readLine user input to download (or not) a PDF file from a website.
async function download_fallo(page) {
if (download == "Y") {
await Promise.all([
page.click('div > div.col-xs-12.col-sm-11 > div.row > div.col-sm-4.col-lg-3 > a'),
page.waitFor(2000)
]);
return console.log("Perfect")
} else if (download == "N") {
console.log("Just the information then!") }
}
I dont really know what you need because i need more context, but if you want to execute an array of promises you could try
Promise.all([ promise1, promise2 ])
This method takes an array of promises as an input, and returns a single Promise as an output. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/all
I am not a 100% sure if your script does what you expect to do, but ‘page.wait’ is a non-existent puppeteer method. You need ‘page.waitFor’ if you want to wait for / pause the script for certain ms-s.
About two months ago we started using Rollbar to notify us of various errors in our Web App. Ever since then we have been getting the occasional error:
ResizeObserver loop limit exceeded
The thing that confuses me about this is that we are not using ResizeObserver and I have investigated the only plugin which I thought could possibly be the culprit, namely:
Aurelia Resize
But it doesn't appear to be using ResizeObserver either.
What is also confusing is that these error messages have been occuring since January but ResizeObserver support has only recently been added to Chrome 65.
The browser versions that have been giving us this error are:
Chrome: 63.0.3239 (ResizeObserver loop limit exceeded)
Chrome: 64.0.3282 (ResizeObserver loop limit exceeded)
Edge: 14.14393 (SecurityError)
Edge: 15.15063 (SecurityError)
So I was wondering if this could possibly be a browser bug? Or perhaps an error that actually has nothing to do with ResizeObserver?
You can safely ignore this error.
One of the specification authors wrote in a comment to your question but it is not an answer and it is not clear in the comment that the answer is really the most important one in this thread, and the one that made me comfortable to ignore it in our Sentry logs.
This error means that ResizeObserver was not able to deliver all observations within a single animation frame. It is benign (your site will not break). – Aleksandar Totic Apr 15 at 3:14
There are also some related issues to this in the specification repository.
It's an old question but it still might be helpful to someone. You can avoid this error by wrapping the callback in requestAnimationFrame.
For example:
const resizeObserver = new ResizeObserver(entries => {
// We wrap it in requestAnimationFrame to avoid this error - ResizeObserver loop limit exceeded
window.requestAnimationFrame(() => {
if (!Array.isArray(entries) || !entries.length) {
return;
}
// your code
});
});
If you're using Cypress and this issue bumps in, you can safely ignore it in Cypress with the following code in support/index.js or commands.ts
const resizeObserverLoopErrRe = /^[^(ResizeObserver loop limit exceeded)]/
Cypress.on('uncaught:exception', (err) => {
/* returning false here prevents Cypress from failing the test */
if (resizeObserverLoopErrRe.test(err.message)) {
return false
}
})
You can follow the discussion about it here.
As Cypress maintainer themselves proposed this solution, so I believe it'd be safe to do so.
We had this same issue. We found that a chrome extension was the culprit. Specifically, the loom chrome extension was causing the error (or some interaction of our code with loom extension). When we disabled the extension, our app worked.
I would recommend disabling certain extensions/addons to see if one of them might be contributing to the error.
For Mocha users:
The snippet below overrides the window.onerror hook mocha installs and turns the errors into a warning.
https://github.com/mochajs/mocha/blob/667e9a21c10649185e92b319006cea5eb8d61f31/browser-entry.js#L74
// ignore ResizeObserver loop limit exceeded
// this is ok in several scenarios according to
// https://github.com/WICG/resize-observer/issues/38
before(() => {
// called before any tests are run
const e = window.onerror;
window.onerror = function(err) {
if(err === 'ResizeObserver loop limit exceeded') {
console.warn('Ignored: ResizeObserver loop limit exceeded');
return false;
} else {
return e(...arguments);
}
}
});
not sure there is a better way..
add debounce like
new ResizeObserver(_.debounce(entries => {}, 200);
fixed this error for me
The error might be worth investigating. It can indicate a problem in your code that can be fixed.
In our case an observed resize of an element triggered a change on the page, which caused a resize of the first element again, which again triggered a change on the page, which again caused a resize of the first element, … You know how this ends.
Essentially we created an infinite loop that could not be fitted into a single animation frame, obviously. We broke it by holding up the change on the page using setTimeout() (although this is not perfect since it may cause some flickering to the users).
So every time ResizeObserver loop limit exceeded emerges in our Sentry now, we look at it as a useful hint and try to find the cause of the problem.
In my case, the issue "ResizeObserver - loop limit exceeded" was triggered because of window.addEventListener("resize" and React's React.useState.
In details, I was working on the hook called useWindowResize where the use case was like this const [windowWidth, windowHeight] = useWindowResize();.
The code reacts on the windowWidth/windowHeight change via the useEffect.
React.useEffect(() => {
ViewportService.dynamicDimensionControlledBy(
"height",
{ windowWidth, windowHeight },
widgetModalRef.current,
{ bottom: chartTitleHeight },
false,
({ h }) => setWidgetHeight(h),
);
}, [windowWidth, windowHeight, widgetModalRef, chartTitleHeight]);
So any browser window resize caused that issue.
I've found that many similar issues caused because of the connection old-javascript-world (DOM manipulation, browser's events) and the new-javascript-world (React) may be solved by the setTimeout, but I would to avoid it and call it anti-pattern when possible.
So my fix is to wrap the setter method into the setTimeout function.
React.useEffect(() => {
ViewportService.dynamicDimensionControlledBy(
"height",
{ windowWidth, windowHeight },
widgetModalRef.current,
{ bottom: chartTitleHeight },
false,
({ h }) => setTimeout(() => setWidgetHeight(h), 0),
);
}, [windowWidth, windowHeight, widgetModalRef, chartTitleHeight]);
One line solution for Cypress. Edit the file support/commands.js with:
Cypress.on(
'uncaught:exception',
(err) => !err.message.includes('ResizeObserver loop limit exceeded')
);
https://github1s.com/chromium/chromium/blob/master/third_party/blink/renderer/core/resize_observer/resize_observer_controller.cc#L44-L45
https://github1s.com/chromium/chromium/blob/master/third_party/blink/renderer/core/frame/local_frame_view.cc#L2211-L2212
After looking at the source code, it seems in my case the issue surfaced when the NotifyResizeObservers function was called, and there were no registered observers.
The GatherObservations function will return a min_depth of 4096, in case there are no observers, and in that case, we will get the "ResizeObserver loop limit exceeded" error.
The way I resolved it is to have an observer living throughout the lifecycle of the page.
Managed to solve this in React for our error logger setup.
The Observer error propagates to the window.onerror error handler, so by storing the original window.onerror in a ref, you can then replace it with a custom method that doesn't throw for this particular error. Other errors are allowed to propagate as normal.
Make sure you reconnect the original onerror in the useEffect cleanup.
const defaultOnErrorFn = useRef(window.onerror);
useEffect(() => {
window.onerror = (...args) => {
if (args[0] === 'ResizeObserver loop limit exceeded') {
return true;
} else {
defaultOnErrorFn.current && defaultOnErrorFn.current(...args);
}
};
return () => {
window.onerror = defaultOnErrorFn.current;
};
}, []);
I had this issue with cypress tests not being able to run.
I found that instead of handling the exception the proper way was to edit the tsconfig.json in a way to target the new es6 version like so:
{
"extends": "../tsconfig.json",
"compilerOptions": {
"baseUrl": "../node_modules",
"target": "es5", --> old
"target": "es6", --> new
"types": ["cypress", "#testing-library/cypress"],
"sourceMap": true
},
"include": [
"**/*.ts"
]
}
What is this bug? When sending web pushing browser Google Chrome "sometimes" gives a second message with the text: "This site has been updated in the background."
I want to make it only one message
This text I found in source Chrome
This site has been updated in the background.
github.com/scheib/chromium/blob/master/chrome/app/resources/generated_resources_en-GB.хтб
How to get rid of this message.
The way it works is a feature not a bug.
Here is an issue that explains your situation in Chrome: https://code.google.com/p/chromium/issues/detail?id=437277
And more specific code comment in Chromium code:
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/push_messaging/push_messaging_notification_manager.cc&rcl=1449664275&l=287
What might have happened is some of the push messages sent to the client did not result in showing a notification.
Hope that helps
The reason this often occurs is the promise returned to event.waitUntil() didn't resolve with a notification being shown.
An example that might show the default push notification:
function handlePush() {
// BAD: The fetch's promise isn't returned
fetch('/some/api')
.then(function(response) {
return response.json();
})
.then(function(data) {
// BAD: the showNotification promise isn't returned
showNotification(data.title, {body: data.body});
});
}
self.addEventListener(function(event) {
event.waitUntil(handlePush());
});
Instead you could should write this as:
function handlePush() {
// GOOD
return fetch('/some/api')
.then(function(response) {
return response.json();
})
.then(function(data) {
// GOOD
return showNotification(data.title, {body: data.body});
});
}
self.addEventListener(function(event) {
const myNotificationPromise = handlePush();
event.waitUntil(myNotificationPromise);
});
The reason this is all important is that browsers wait for the promise passed into event.waitUntil to resolve / finish so they know the service worker needs to be kept alive and running.
When the promise resolves for a push event, chrome will check that a notification has been shown and it falls into a race condition / specific circumstance as to whether Chrome shows this notification or not. Best bet is to ensure you have a correct promise chain.
I put some extra notes on promises on this post (See: 'Side Quest: Promises' https://gauntface.com/blog/2016/05/01/push-debugging-analytics)
I am creating an element (a router - but that is not important), that is scanning the DOM soon after it has attached for particular other custom elements. I certain cases it needs to throw an error and I want to test for these.
The test I constructed is not failing - but as far as I can make out the test has already failed before my element gets attached. I suspect it is the asynchronous nature of things.
Here is the snippet of the test in question. The test fixture in question contains elements that will cause one of the elements to fail after a 'dom-change' event happens (which it has a listener for) when it then scans the dom for other things.
it('should fail if two route elements both designate thenselves as home', function(done) {
var t= document.getElementById('multiple_home');
function multiple () {
t.create();
}
expect(multiple).to.throw(Error);
t.restore();
done();
});
I think the problem is related to the fact that the fixture is created in multiple, but hasn't yet failed by the time multiple exits. I am wondering if I can pass a Promise to expect - except I am not sure how to turn mulitple into a Promise to try it out.
I eventually found a way, but it requires instrumenting the element a bit to support this.
In the elements "created" callback I create a Promise and store the two functions to resolve and reject it in "this" variables - thus:-
this.statusPromise = new Promise(function(resolve,reject){
this.statusResolver = resolve;
this.statusRejector = reject;
}.bind(this));
In the DOM parsing section I use a try catch block like this
try {
//parse the dom throwing errors if anything bad happens
this.statusResolver('Any useful value I like');
} catch (error) {
this.statusRejector(error);
}
I then made a function that returns the promise
domOK: function() {
return this.statusPromise;
}
Finally in my test I was now able to test something like this (I load the fixture in each test, rather than a beforeEach, because I am using a different fixture for each test. I do clear it down again in an afterEach). Note the use of the .then and .catch functions from the Promise.
it('should fail if two route elements declare the same path name',function(done){
t = document.getElementById('multiple_path');
t.create();
r = document.getElementById('router')
r.domOK().then(function(status){
//We should not get here throw an error
assert.fail('Did not error - status is: ' + status);
done();
}).catch(function(error){
expect(error.message).to.equal('There are two nodes with the same name: /user');
done();
});
In jQuery, if you make a mistake in your ajax callback method, you will get a proper console error message and stacktrace.
$.get("https://api.github.com/users/octocat/orgs", function() {
var a = FAIL;
});
However, in dojo using dojo/request/xhr it seems these dumb mistakes are being swallowed completely. The only thing in my console when I run this is "then" and "always".
require(["dojo/request/xhr" ], function(xhr) {
var promise = xhr.get("https://api.github.com/users/octocat/orgs");
promise.then(function(data) {
console.log('then');
var a = FAIL;
console.log('goodbye');
}, function() {
console.log('error');
});
promise.otherwise(function() {
console.log('otherwise');
});
promise.always(function() {
console.log('always');
});
});
Using the deprecated dojo.xhrGet, the problem is very slightly improved. I get a console error message and my error handler is called but it only says "ReferenceError {}" and provides me with a stack trace that never points to a function I own:
dojo.xhrGet({
url: "https://api.github.com/users/octocat/orgs",
load: function() {
console.log('dojo.xhrGet.load');
var a = FAIL;
console.log('goodbye dojo.xhrGet.load');
},
error: function() {
console.log('dojo.xhrGet.error');
},
handle: function() {
console.log('dojo.xhrGet.handle');
}
});
When writing a program we make mistakes, it's nice that we have tools like chrome developer tools to point us to those mistakes. The time it takes to find an error when you can see a stacktrace and error message is obviously much quicker than if you get no feedback. I get no feedback in dojo, I can't believe that such a popular library could operate in this way. What am I doing wrong?
The understanding of promises which you inherited from jQuery is fundamentally different to the one everyone else (check Promises/a+ implementations) has. For the rest of this answer I will talk about promises/a+ compliant promises. Dojo's Deferred actually isn't a+ compliant, but it's close enough that everything I discuss here applies equally well.
Promises are immutable, you cannot change a promises state by calling then. A promise represents an eventual value, it would be nonsensical to be able to change the promise by saying "once the value is ready, do this".
So then, hopefully that explains why your error handler is not invoked, but the basic idea, of catching errors, is still totally possible. You just need to use return values. When you call then on a promise, it returns a new and (almost always) different promise. This new promise is very special, if the original is resolved, and the success handler you passed is invoked, and that returns something, that something will be the resolution value of the second promise.
Equally, if the error handler (on the first promise) is triggered, and that function returns something, that something will be the resolution value of the second promise. The same is true for thrown errors, they are passed to the error handler (of the second promise!).
So here's your first code sample written in a more promises/a+ way :
require(["dojo/request/xhr" ], function(xhr) {
var promise = xhr.get("https://api.github.com/users/octocat/orgs");
promise.then(function(data) {
console.log('then');
var a = FAIL;
console.log('goodbye');
}, function() {
console.log('error');
}).then(null, function() {
console.log('otherwise');
});
promise.always(function() {
console.log('always');
});
});
I don't really understand what you want to do with the always function, so I wasn't sure where to place that one. On the subject of call stacks, I would recommend checking out the Q promise library which has incredibly advanced asynchronous call stack support.
In dojoConfig set useDeferredInstrumentation: true. Here's an example.
<script>
var dojoConfig = {
useDeferredInstrumentation: true
};
</script>
<script src="js/lib/dojo/dojo.js.uncompressed.js"></script>
This gives a fairly functional error message and stacktrace output on console.error:
ReferenceError {} "ReferenceError: FAIL is not defined
at http://fiddle.jshell.net/gNdCb/2/show/:25:17
at signalListener (http://ajax.googleapis.com/ajax/libs/dojo/1.9.0/dojo/dojo.js.uncompressed.js:14205:21)
at signalWaiting (http://ajax.googleapis.com/ajax/libs/dojo/1.9.0/dojo/dojo.js.uncompressed.js:14196:4)
at resolve (http://ajax.googleapis.com/ajax/libs/dojo/1.9.0/dojo/dojo.js.uncompressed.js:14360:5)
at signalDeferred (http://ajax.googleapis.com/ajax/libs/dojo/1.9.0/dojo/dojo.js.uncompressed.js:14249:15)
at signalListener (http://ajax.googleapis.com/ajax/libs/dojo/1.9.0/dojo/dojo.js.uncompressed.js:14220:6)
at signalWaiting (http://ajax.googleapis.com/ajax/libs/dojo/1.9.0/dojo/dojo.js.uncompressed.js:14196:4)
at resolve (http://ajax.googleapis.com/ajax/libs/dojo/1.9.0/dojo/dojo.js.uncompressed.js:14360:5)
at signalDeferred (http://ajax.googleapis.com/ajax/libs/dojo/1.9.0/dojo/dojo.js.uncompressed.js:14249:15)
at signalListener (http://ajax.googleapis.com/ajax/libs/dojo/1.9.0/dojo/dojo.js.uncompressed.js:14226:4)
----------------------------------------
rejected at signalDeferred (http://ajax.googleapis.com/ajax/libs/dojo/1.9.0/dojo/dojo.js.uncompressed.js:14252:15)
at signalListener (http://ajax.googleapis.com/ajax/libs/dojo/1.9.0/dojo/dojo.js.uncompressed.js:14223:5)
at signalWaiting (http://ajax.googleapis.com/ajax/libs/dojo/1.9.0/dojo/dojo.js.uncompressed.js:14196:4)
at resolve (http://ajax.googleapis.com/ajax/libs/dojo/1.9.0/dojo/dojo.js.uncompressed.js:14360:5)
at signalDeferred (http://ajax.googleapis.com/ajax/libs/dojo/1.9.0/dojo/dojo.js.uncompressed.js:14249:15)
at signalListener (http://ajax.googleapis.com/ajax/libs/dojo/1.9.0/dojo/dojo.js.uncompressed.js:14220:6)
at signalWaiting (http://ajax.googleapis.com/ajax/libs/dojo/1.9.0/dojo/dojo.js.uncompressed.js:14196:4)
at resolve (http://ajax.googleapis.com/ajax/libs/dojo/1.9.0/dojo/dojo.js.uncompressed.js:14360:5)
at signalDeferred (http://ajax.googleapis.com/ajax/libs/dojo/1.9.0/dojo/dojo.js.uncompressed.js:14249:15)
at signalListener (http://ajax.googleapis.com/ajax/libs/dojo/1.9.0/dojo/dojo.js.uncompressed.js:14226:4)
----------------------------------------
Error
at Promise.then.promise.then (http://ajax.googleapis.com/ajax/libs/dojo/1.9.0/dojo/dojo.js.uncompressed.js:14420:24)
at http://fiddle.jshell.net/gNdCb/2/show/:23:13
at runFactory (http://ajax.googleapis.com/ajax/libs/dojo/1.9.0/dojo/dojo.js.uncompressed.js:1117:43)
at execModule (http://ajax.googleapis.com/ajax/libs/dojo/1.9.0/dojo/dojo.js.uncompressed.js:1245:5)
at http://ajax.googleapis.com/ajax/libs/dojo/1.9.0/dojo/dojo.js.uncompressed.js:812:7
at guardCheckComplete (http://ajax.googleapis.com/ajax/libs/dojo/1.9.0/dojo/dojo.js.uncompressed.js:1260:5)
at contextRequire (http://ajax.googleapis.com/ajax/libs/dojo/1.9.0/dojo/dojo.js.uncompressed.js:811:6)
at req (http://ajax.googleapis.com/ajax/libs/dojo/1.9.0/dojo/dojo.js.uncompressed.js:137:11)
at http://fiddle.jshell.net/gNdCb/2/show/:21:1"
I had very specific needs in that I needed the exception to hit the native catch clause that the browser implements. Nevermind why I needed this, But I used something like this:
function scream(func) {
return function() {
var args = arguments;
setTimeout(function(){
func.apply(null, args);
}, 0);
};
}
Then, to use it
var promise = xhr.get("https://api.github.com/users/octocat/orgs");
promise.then(scream(function(data) {
//do stuff
}));
By using setTimeout, you execute the function on the browsers event queue, making it impossible for dojo to swallow your exception. But, in general this is a bad solution because:
it changes part of the stack trace
it changes a part of your code which previous executed synchronously to asynchronously, which can change program behavior
you can't chain multiple .then() promise objects to the return value, which is one of the really nice things about promises.
Anyway, I'm just presenting it as option.