We Keep Coding

JS : How to get notified after insertBefore()?

Is there a way to get notified, after inserting an element into the DOM with insertBefore(), when this element becomes actually visible/available to user ? Especially to start applying CSS transforms on it ?
Complete problem
Forgive me if this question is recurrent, I didn't find a suitable answer so far. I'm trying to implement a custom popup dialog system on a website of my own, similar to SweetAlert or some other products.
I would like to apply some special effects when this popup shows up, such as a progressive darkening of the background, as well as a slow vertical motion on the box itself.
To achieve all of this, I spawn one big, fixed div element covering the whole screen (the background) and containing the popup box. When I need it, I first insert this element as body's first child, tagging it with a special invisible class. Once inserted, I remove this invisible class from the element and let the CSS rules do the magic.
The problem is that even if removed the class after having inserted this element, this one will be rendered only when the Javascript function leaves, hence directly in its final state.
When doing this on a complete initial page, the load event helps. I now would like to do the same on an existing page.
As always, I'm interested on both solutions to this (potentially XY) problem: if there's a better way to do it, I'll be happy to discover it, but I'm still interested in solving this particular situation anyway.
Thanks in advance to everyone.
EDIT: currently performing tests on Firefox 82.0.2

Thanks to comments above, here's a valid solution to both exposed problems:
"Mutation Observer", as well as former "Mutation Events" (now deprecated) are the best way to get notified when something is inserted. It won't help with animations issues, though, because it's still not guaranteed to be rendered yet at this time ;
Rather than applying a class then another to perform a transition, it's better to define a regular animation using #keyframes that plays only once. It's guaranteed to be played when the object appears, by definition.
Many thanks to "Pomax", F4st3r and epascarello for their help.

Testcafe can see button but not click on it

In a testcafe test how can I click on an element that is clearly clickable (with t.debug() I'm able to click on the element) and visible without using ClientFunction, or t.eval -- these "workarounds" recommended in testcafe's github issues do not work.
Some additional considerations:
the code I'm testing is Angular 1.7.
the Selector is verified as correct (and I tried various types of selectors)
testcafe version 1.8.4
I've tried various t.wait times before and after selection and click
I've tried changing the element type (<button> to <div>, etc)

Try waiting for the element to be visible before clicking
await element.with({ visibilityCheck: true }).with({timeout: 10000});

Here are some typical problems with unclickable elements, I know the link is for Selenium issues, but some solutions can be used regardless of the technology used.
If you already tried with various waiting to be visible/clickable solutions, the next thing that you might want to check is if you have multiple elements with the same id, one of them being invisible, so TestCafe is unable to uniquely identify the right element. In that case, you will need to improve the locator.
Another thing to consider is that the element might be out of the viewport (when not debugging). In that case, try changing the window size (or maximizing it) or moving to element.

How to tell screenreader to read a toggled element

Instead of adding/removing my different sections to/from the DOM, I'm only hiding them with aria-hidden="true", and unhiding them if certain <a> toggles are clicked.
Reasons are performance and an easier noscript fallback. The order in the DOM is not the order in which the questions appear.
The result is a binary question tree (yes/no questions) in which the user clicks from one question to the next.
Now what would be a good solution to make screen readers read a section or at least continue reading it next after unhiding it?
Is there a way with live-region? Do screenreaders read elements that become unhidden in it? I thought aria-current might be appropriate? Or is it more an aria-expanded application?
Thanks for your help!

ARIA live regions are without question the correct way to handle this sort of problem.
By using the aria-live attribute on an HTML element, assistive technology will be alerted when content is changed in one of these areas. Your choice of attribute value will specify how quickly the change is announced (immediately, or at next graceful opportunity). The most common implementation is typically aria-live="polite".
This page outlines some pretty useful (and innovative) techniques for implementing live regions: https://terrillthompson.com/tests/aria/live-scores.html

disableSelection on everything but input[type=text]

I have a requirement to disable selection on a web page for everything except input[type=text] elements.
This accepted answer to a similar question almost does the trick, but it doesn't disable selection for containers that contain input[type=text] elements. Therefore the user can still select by starting a drag operation from within one of these containers.
Is this even possible, i.e. is it possible to disable selection for a container element, while enabling it for child elements (specifically, child input=text elements).
#Pointy, "Why not just take out that first .not() call?"
Taking out the first .not call, will give:
$('body').not('input').disableSelection();
which, as pointed out in the linked question, will still disable everything on the page, including the input[type=text] elements.
#David Thomas, "Do you have a live demo ..."
I don't have a live demo, but it's fairly trivial. For example, a div with a bit of padding that contains an input[type=text] element. The result is:
With $('body').not('input').disableSelection(); selectiopn is disabled for all the page, including the input elements.
With $('body *').not(':has(input)').not('input').disableSelection(); selection is disabled for all elements that don't contain an input element. But it is possible to select the whole page by starting a drag operation from within a container that contains an input element.

Well, cinch up your suspenders and get ready for a really dirty hack.
Disclaimer:
I don't think this is a good way to do things. I simply wanted to tackle the challenge of getting the OP's desired functionality. If someone else can get this to work in a cleaner way, please post it.
After playing around with the disableSelection() function, it seemed that if a parent element had been disabled, all of its children would be unselectable as well (please correct me if I'm wrong). So, I decided that if you wanted everything to be unselectable except small parts, you could put all of your markup in one unselectable <div> and use absolute positioning to place selectable clones of your <input> tags (or any tag, really) on top of the unselectable ones. These clones would reside in a second <div> that was not disabled.
Here's an example of this idea: http://jsfiddle.net/pnCxE/2/.
Drawbacks:
Styling becomes a big headache. Any element that relies on a parent's style (i.e., position, size, colors, etc.) cannot be cloned since the clones reside in a separate place.
Forms become much harder to manage since (again) the clone isn't in the same place as the cloned element.
You have to deal with naming collisions since the clone will have the same ID as the cloned element. (It's doable; I just didn't want to code it since it would probably need specific attention by anyone that uses this idea)
So, while you can work around the selectable limitations, you might be better off just accepting the container selection. I would think long and hard before putting this code into a production environment.

I've found a solution that appears to do what I want, and would be interested in comments / improvements from jquery / javascript experts.
$(document).ready(function () {
$("body").disableSelection();
$("body").delegate('input[type=text],textarea', "focus", function () {
$("body").enableSelection();
});
$("body").delegate("input[type=text],textarea", "blur", function () {
$("body").disableSelection();
});
});
When a textbox (input[type=text] or textarea) has the focus, then dragging with the mouse only selects text within the textbox. Therefore it's "safe" to enable selection for the whole page while a textbox has focus (between focus and blur events).
There is a noticeable delay when tabbing between textboxes on IE8/9. It's not noticeable on Google Chrome, which I understand has a faster javascript engine. So I can live with the performance hit, especially since IE10 is going to have a faster javascript engine.
UPDATE
When using ASP.NET UpdatePanel, this needs to be modified to disable selection after each partial postback:
Sys.Application.add_load(function () {
$("body").disableSelection();
});

Try this, although it is same with what you're already using:
$('* :not(input)').disableSelection();
I don't get though why do you have to use entire body element and not narrow it down to text nodes (p, h[..], ul, ol etc.)
And I agree with #David Thomas - it would be easier to see a test page you're working on.

Partially select checkbox with javascript

Is there a way using Javascript and HTML(5) to make a checkbox be partially selected, like the checkboxes in a program installation menu when you select only some of the sub options?

HTML5 defines the indeterminate boolean property.
I've tested it only in the latest Safari, Chrome, and Firefox. They all support the indeterminate state.
Example: http://jsfiddle.net/5tpXc/
Edit: Note that this wont work with older browsers and maybe not with current versions of IE. You'd need to rely on hacks as described in other answers here if you want to support all browsers.

HTML checkboxes (that is, input elements of type checkbox) don't have a third state (partially checked). So no, there is no direct way to do this.
What you'd probably have to do is make a custom checkbox-looking image and bind to its various events (click, for example) to store its current "state" in a hidden form field via JavaScript. You may run into a number of issues with this approach, though.
For example, keyboard navigation of the form may not be possible for this particular element. (Can one tab to an image and send it keyboard events? I'm not sure.)
Additionally, you could try manipulating custom attributes on a checkbox element via JavaScript to store a third state. But the rendering of the element itself has no visual indicator of something like that. You could probably manipulate its style (color, background color, border color, etc.) to try to mimic the visual behavior. But you may not be able to achieve the exact visual style that you're using for reference.
It's certainly an interesting prospect, and I'm intrigued enough that I may try to implement something like this in the near future. But with a native checkbox element, it's not possible. It has only two states.
Edit: Refer to #kassens' answer for doing this in HTML5. If you're limited to previous versions of HTML for any reason, then it's going to have to be a hack as described here. But if you can rely on users supporting HTML5, then it looks like native support is there.

Nope. You would have to make a custom checkbox graphic and fake it.
Edit: Refer to #Kassen's answer for a way to have partially checked boxes in HTML5-compliant browsers.