Please understand that it will be difficult for me to post snippets of code, but the problem is easy to summarize.
A modal becomes visible.
I click anywhere OUTSIDE of the modal (we are still in the modal here, and experiencing zero lag).
The modal is closed.
Suddenly everything is very laggy, until I click on any element that IS NOT bound to a .click listener, after which the lag is completely gone.
Because of step #4, it seems to behave similarly to a recursive function. When I finally click on something not listening for a click, it returns all the way back up and all is well. Until then, I just burrow deeper into the rabbit hole.
Notes:
This applies to all modals in the DOM.
If a modal is closed using ESC or the 'Close' button, there is no lag. The issue only arises when I click outside of the modal.
I'm not dynamically creating anything here, not even the modals, so I don't have a straightforward idea of why memory usage would be increasing.
There is never more than one modal open at a time (tested via extensive logging).
I happen to have 'data-background="static"' set so that the modals don't auto-close when you click outside of them, but this doesn't have any effect on the issue. With or without it, the same issue crops up.
Related
So, I've probably stumbled upon the strangest bug/feature I've ever seen. I've developed a website which helps you read foreign books. See this book (or any book on the website, it doesn't matter): https://anylang.net/en/books/de/heaven-has-no-favorites/read.
Try to quickly move your mouse hovering on words/sentences, maybe click on something etc. Everything should work pretty smooth.
On mouseover a word quickly becomes orange, on click the translation quickly appears etc.
Now click on the login button:
The first input should become focused.
Then close the modal and try the first step again. Everything becomes very laggy. The lags won't disappear no matter what you do, except:
Click on the page number:
Lags disappear. Completely.
The same result (lags) can be achieved by:
Clicking on a word inside a translation tooltip
It has a contenteditable attribute, so the behaviour is exactly the same as in the first case.
Click anywhere outside the tooltip, closing it and causing the lags.
Lags still disappear if you click on a page number (or, probably, any input[type="text"] on the page (but not in modals))
Some things to consider:
The effect doesn't disappear if you lose focuse in a modal and then close it.
The same effect can be achieved by focusing in a modal and then manually removing a modal from dom. So javascript is not the problem.
If you don't remove a modal from dom but apply "display: none" to it instead, everything is ok, no lags.
My guess is that the browser gives higher priority to elements where input[type="text"] is focused and doesn't respect it when an element with the input is removed from dom. Any other ideas? This thing really boggles my mind.
If you do a performance profile of your site while going through this process, you'll see that your memory allocation continues to climb as you interact with the page. You'll also notice that the more text you hover over the worse the lag eventually becomes.
This is indicative of a memory leak in your code - possibly caused by event listeners that aren't being cleaned up properly.
Without an in-depth review of your code it's unlikely anyone here is going to be able to pinpoint where the exact problem is, but hopefully I've pointed you in the right direction!
Im having an issue with modal in React. The problem is Modal closes if I click inside content and move mouse and release outside. This shouldnt happen.
Currently it works fine because if I click outside content the modal closes, but if I click inside, the modal stays.
But dragging mouse click from inside to outside closes it...
https://codesandbox.io/s/awesome-newton-fqe6b
Looking for help! Thanks!
I do experience the behavior you're describing. Pretty weird, I was under the impression that e.target in this instance would always refer to the interior div if the click event was initiated on that element, but maybe that's not accurate. I tried using stopPropagation(), but it doesn't work because the click event seems to completely ignore the element that the mousedown portion of the click was actually initiated on.
I made a hacky workaround that will save the initial target in the state for comparison with the currentTarget and achieve the effect you're looking for, but this definitely bears some looking in to.
I've got dialog that I wrote and it closes when clicking outside (no overlay/backdrop).
It works nicely unless there's an iframe, in which case my listener on outside clicks is never called.
Here is a JSBIN to illustrate the problem. (http://jsbin.com/vuneyopedu/edit?js,console,output)
To briefly explain in the below screenshot:
Clicking RED Dialog Increments.
Clicking Outside Dialog (YELLOW and GREEN) should Decrement but only YELLOW works.
The event listener for outside clicks is never called when clicking iframe (GREEN)
Question is - How do I make clicking anything outside the RED square (specifically clicking the iframe) decrement the number. (or close the dialog, in the "real" world)
How about binding event to iframes' document.
iframes = document.getElementsByTagName('iframe');
iframesArray = Array.prototype.slice.apply(iframes);
iframesArray.forEach(function(frame) {
frame.contentWindow.document.addEventListener('click', function() {
inc();
}, true);
});
The correct approach here is to use a modal and one of the strongest use-cases for the modal. By design modals prevent clicks from falling through to elements below hence there is no need to handle side effects like your iframe issue or e.stopPropagation() or anything else. It also makes positioning very clean.
As a side note, the currently accepted answer is a very poor approach since it relies on adding an event handler inside the iFrame, then binding that onto the parent container window. This is wrong on many levels: no separation of concerns, iframe from different domains will be blocked due to CORS, iframe will register with any and all parents even when not needed, etc.
I want to pop up a window.alert() if the user mouses out of an area when they haven't saved changes yet (for structural reasons, there are several forms and a common problem I've seen in other apps is making changes in multiple areas, submitting one and losing the rest) and automatically close the alert when they mouse back into the area. To do that, I need the id of the window that pops up, but I'm not sure how to get it.
The window does not have an id, and you cannot close it from Javascript. It is not a part of the DOM.
You can only open an alert() box, and then wait till the user closes it. Nothing else.
No alert() please :)
Actually an alert() will block further code execution anyway so even if you COULD close it programatically it would never actually execute that dialog-closing code.
You need something you can access through the DOM (like every other response here says).
Make your Javascript track the mouse location and upon leaving the area you overlay a dark translucent background or do a modal dialog
Techniques on creating modal dialogs
I would also advise adding a pointer-events: none; and position: fixed to the underlying content to prevent further action until the user actually goes back where they should be.
If you want real specifics on how to code this let me know. I'm hoping you'll travel down the rabbit hole and discover the wonders on your own, though. Much more satisfying.
I have a page that uses JQuery UI Tabs and some other bits and pieces. When a user opens this page and quickly clicks on some tab, after a second or so the page reverts to the first tab again!
I am trying to use Firebug to see what's going on, but as far as I can see, when that reversion occurs the body tag highlights, but nothing within it. I am a novice with Firebug - how can I use it to better understand what's going on here?
I can only take a guess without a concrete example, but it sounds you're initialising the tabs twice. The tabs must already be enabled which is allowing the initial navigation between tabs. Then a second initialisation of the tabs is resetting the view back to the first tab.
You are initialising the tabs inside $(document).ready and not window.onload, right?