We Keep Coding

Browser Extension: How to execute a function when an element is loaded

I am working on a browser extension.
It has two parts:
popup - which contains checkboxes
content script - which contains the code to alter the CSS property
I am saving the states of checkboxes so that the next time I open the popup again the same checkboxes are marked as checked.
When I use the checkboxes they change the DOM as intended, however when I try to alter the DOM after the page is loaded, changes are not reflected. This is probably because the element on which I want to perform the operation is loaded slow and thus required operations fail.
I tried to use onload and ready but nothing worked
$('.question-list-table').on('load', function() {
browser.storage.local.get(["options"], modifyThenApplyChanges)
});
I also tried, but nothing changed.
$('body').on('load','.question-list-table', function() {
browser.storage.local.get(["options"], modifyThenApplyChanges)
});
Also, there is no visible error with the popup or content script as I test in both Google Chrome and Mozilla Firefox.
Update:
As suspected earlier, the target element is loaded slowly so I used setTimeout for 5 seconds and the script is working as intended.
Loading time is variable and I want to show my changes as early as possible everything in a consistent manner.

After going through MutationObserver as suggested by #charlietfl in the comment section, this is what I coded and works for me
// Mutation Observer
const observer = new MutationObserver(function (mutations) {
mutations.forEach(function(mutation) {
if(mutation.addedNodes.length) {
//do stuff
}
});
});
el = document.getElementsById('elementId');
if(el) {
observer.observe(el, {
childList: true // specify the kind of change you are looking for
});
}

Preventing textarea scroll behaviour in chrome after newline added

Recently my version of chrome has been doing something strange (74.0.3729.131 on ubuntu 18.04) more and more often. I have a small editor script which has a textarea which displays code. The textarea has a fixed size and a vertical scroll bar. Beyond that nothing fancy.
Usually, when I insert a newline (normal behaviour of textarea), the scroll bar doesn't move. Now for some reason about 80% of the times it scrolls the textarea down till the position of the caret is at the top of the textarea. Strangely if I delete and enter the newline in the same position, it usually does not scroll.
I'm not sure if this is some new issue in Chrome. I usen't have this issue with previous versions with the identical editor.
Here is a codepen which demonstrates the issue, scroll to some line, press enter and the textarea should scroll down. Try this a few times to see the unpredictable behaviour (adding the code just to be able to add the link, as you can see it's just a textarea).
https://codepen.io/anon/pen/rgKqMb
<textarea style="width:90%;height:300px"></textarea>
The only solution that occurs to me to avoid this is to stop the normal behaviour of the enter key and add the newline to the text. Any other ideas/insights very much welcome.

It's almost the end of 2020, Chrome version 86 and this issue still exists? What's more, I am surprised I have not found more information (complaints) on this matter (this post is the only thing I've found which speaks of this issue specifically.) I have observed that this behavior occurs not only in typing, but pasting any text containing a newline. I also observed that if I execute an undo action after this occurs, another random scroll happens, taking me even farther up the page, and nowhere near where the caret is.
I experimented and examined this behavior at much length, and was not able to find any repeatable circumstances which might give a clue as to how to predict when this would occur. It truly just seems "random". Nonetheless, I've had to work around this issue for an NWJS editor app I'm creating (NWJS uses Chrome for UI.)
This is what seems to be working for me:
First all, let me start simple in order to introduce the principle. We attach an "input" listener and "scroll" listener to the textarea. This works because, from my observation anyway, the "input"[1] listener gets fired before the random scroll action occurs.
The scroll listener records each scrolling action and saves it in a global prevScrollPos. It also checks for a global flag scrollCorrection.
The "input" listener sets the scrollCorrection flag everytime text is input into the textarea. Remember, this has happened before the random scroll occurs.
So the next scroll to occur, which may be the nuisance random action, the scroll listener will clear scrollCorrection, then scroll the textarea to the previous scroll position, ie, scrolling it back to where it was before the "random" scroll. But the issue is unpredictable, what if there is no random scroll and the next scroll to occur is intentional? That is not a big deal. It just means that if the user scrolls manually, the first scroll event is basically nullified, but then after that (with scrollCorrection cleared) everything will scroll normally. Since during normal scrolling, events are spit out so rapidly, it is unlikely there will be any noticeable effect.
Here is the code:
let textarea;
let prevScrollPos = 0;
let scrollCorrection = false;
function onScroll(evt) {
if (scrollCorrection) {
// Reset this right off so it doesn't get retriggered by the corrction.
scrollCorrection = false;
textarea.scrollTop = prevScrollPos;
}
prevScrollPos = textarea.scrollTop;
}
function onInput(evt) {
scrollCorrection = true;
}
window.addEventListener("load", () => {
textarea = document.getElementById("example_textarea");
textarea.addEventListener("scroll", onScroll);
textarea.addEventListener("input", onInput);
})
Now let's expand on it:
There is another consideration. What if the typing or pasting action puts the end of the typed or pasted text (and thus the caret) outside the view of the textarea viewport? When normal scrolling is in play, most browsers will scroll the page[2] so the caret will remain in view. However now that we've taken over scrolling action, we'll need to implement that ourselves.
In the psuedo-code below, on input to the textarea, besides setting scrollCorrection, we call a function which will:
determine the xy position of caret relative to textarea viewport
determine if it is scrolled out of view
if so:
determine the amount to scroll to bring it in view
determine if the random scroll has already occurred by testing the state of scrollCorrection
if it hasn't, set flag scrollCorrection2 containing the amount to scroll
if it has, explicitly do the additional scrolling to bring it back into view
Finding the xy position of the caret in a textarea is not a trivial matter and is outside the scope of this answer, but there are plenty of methods to be found in searching the web. Most involve replicating the textarea contents in a non-form element, eg div block, with similar font, font-size, text wrapping etc, then using getBoundingClientRect on the resultant containing block and such. In my situation, I was already doing most of this for my editor, so it wasn't much of an additional expense. But I've included some psuedo-code to show how this can be implemented in the scroll correction mechanism. setCaretCorrection basically does steps 1 - 7 above.
let textarea;
let prevScrollPos = 0;
let scrollCorrection = false;
let caretCorrection = 0;
function onScroll(evt) {
if (scrollCorrection) {
// Reset this right off so it doesn't get retriggered by the correction.
scrollCorrection = false;
textarea.scrollTop = prevScrollPos + caretCorrection;
caretCorrection = 0;
}
prevScrollPos = textarea.scrollTop;
}
function onTextareaInput() {
scrollCorrection = true;
setCaretCorrection();
}
function setCaretCorrection(evt) {
let caretPos = textarea.selectionStart;
let scrollingNeeded;
let amountToScroll;
/* ... Some code to determine xy position of caret relative to
textarea viewport, if it is scrolled out of view, and if
so, how much to scroll to bring it in view. ... */
if (scrollingNeeded) {
if (scrollCorrection) {
// scrollCorrection is true meaning random scroll has not occurred yet,
// so flag the scroll listener to add additional correction. This method
// won't cause a flicker which could happen if we scrollBy() explicitly.
caretCorrection = amountToScroll;
} else {
// Random scroll has already occurred and been corrected, so we are
// forced to do the additional "out of viewport" correction explicitly.
// Note, in my situation I never saw this condition happen.
textarea.scrollBy(0, amountToScroll);
}
}
}
One could go further and use the experimental event, "beforeinput"[3], to optimize this a little bit so fewer unnecessary calls to setCaretCorrection are made. If one examines event.data from "beforeinput" event, in certain cases it will report the data to be input. If it does not, then it outputs null. Unfortunately, when a newline is typed, event.data is null. However it will report newlines if they are pasted. So at least one can see if event.data contains a string, and if the string does not contain newlines, skip the whole correction action. (Also, see [1] below.)
[1] I also don't see any reason you couldn't do in the "beforeinput"[3] listener, what what we're doing in the "input" listener. That may also give more insurance that we set scrollCorrection before the random scroll occurs. Although note that "beforeinput" is experimental.
[2] I suspect it is broken implementation of this feature which is causing this issue.
[3] https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/beforeinput_event (Available on Chrome and all major browsers except Firefox according to this link.)

You can try avoiding the events on the textarea with css and js, then force the scroll to it's current position:
css:
textarea {
overflow:auto;
resize:none;
width:90%;
height:300px;
}
js:
You'll need to insert the first answer from this question at A
function preventMoving(e) {
var key = (e.keyCode ? e.keyCode : e.which);
if(key == 13) {
e.preventDefault();
// A
}
}
Then on your HTML:
<textarea onkeyup="preventMoving(event);"></textarea>

jQuery `[jQuery created Element].is(":hover")` Only Seems To Work In Chrome

Please see the code below (very stripped back and not my full function). I've also got a fiddle that you can test it at: https://jsfiddle.net/glenn2223/uk7e7rwe/1/
var
hov = $("<div class=\"over\">I'm Over You</div>"),
box = $("<div>Result: WAITING</div>")
$("body").append(hov).append(box);
$("#MeHover").on('mouseleave', function(){
var d = new Date();
box.text("Result: " + hov.is(":hover").toString().toUpperCase() );
});
We have a div and div.over overlaps it slightly. When you move from div to div.over I want the function to return true.
In my full function: this stops it from hiding the div.over element.
Opening it in Chrome it works as expected. However, it's not in pretty much everything else (Tested in: Edge, IE11 and Firefox).

Okay so we've found out why it doesn't work the :hover was removed from .is() a while back.
Rather than changing this question to suit my findings I will ask another (saves confusion).
My New Question: Keep jQuery Appended Element Open When Hovering It

IE and firefox behave unpredictably updating location.hash on scroll()

I'm trying to update the location.hash by checking what div is currently active in a long scrolling site. This works fine is chrome, but is failing in Firefox and IE. I have tested with console.log and
I am able to see the id in console, but as soon as I try to feed this into the location hash the scrolling ceases to work on the page, or jumps around unpredictably!
$(window).scroll(function () {
$('div').each(function(){
if (
$(this).attr('class')=='article' && $(this).offset().top < window.pageYOffset + 10
&& $(this).offset().top + $(this).height() > window.pageYOffset + 10
) {
window.location.hash = $(this).attr('id')
}
});
});

First you need to understand that the scroll event fires many times a second. Combine that with the methodology you are using to search the DOM... look for every div, then filter all those div's for the ones you want and do this all many times a second...you are overloading the browser needlessly.
Scroll the window in this simple demo and see how often your script is firing; http://jsfiddle.net/tRx2P/
If you are going to search the DOM for the same elements repeatedly, caching them into variables will give a big performance boost. Searching the DOM is a lot more expensive than searching a cached variable containing elements
/* use jQuery selector that already filters out all the other `div` in page*/
var $articles= $('.article');
/* now use the variable inside your functions*/
$( window).scroll(function(){
$articles.each(.....
/* use the same cache principles for "$(this)" to help avoid needless function calls*/
})
Now the really important part is you should throttle back the number of times a second these need to be checked. There is no benefit in updating the hash multiple times while the user is still scrolling...and overloading the browser to do it
This modification of the demo only fires the code when user hasn't scrolled for 300ms which could likely be increased to 1/2 second or even more. It does this by constantly setting a timeout delay
http://jsfiddle.net/tRx2P/2/
You should be able to now adapt these concepts to the code you have

Disable Browser Window Resize

For starters... I have no sinister intention of subjecting users to popups or anything like that. I simply want to prevent a user from resizing the browser window of a webpage to which they've already navigated (meaning I don't have access to / don't want to use window.open();). I've been researching this for quite a while and can't seem to find a straightforward answer.
I felt like I was on track with something along the lines of:
$(window).resize(function() {
var wWidth = window.width,
wHeight = window.height;
window.resizeBy(wWidth, wHeight);
});
...to no avail. I have to imagine this is possible. Is it? If so, I would definitely appreciate the help.
Thanks

You can first determine a definite size.
var size = [window.width,window.height]; //public variable
Then do this:
$(window).resize(function(){
window.resizeTo(size[0],size[1]);
});
Demo: http://jsfiddle.net/DerekL/xeway917/
Q: Won't this cause an infinite loop of resizing? - user1147171
Nice question. This will not cause an infinite loop of resizing. The W3C specification states that resize event must be dispatched only when a document view has been resized. When the resizeTo function try to execute the second time, the window will have the exact same dimension as it just set, and thus the browser will not fire the resize event because the dimensions have not been changed.

I needed to do this today (for a panel opened by a chrome extension) but I needed to allow the user to change the window height, but prevent them changing the window width
#Derek's solution got me almost there but I had to tweak it to allow height changes and because of that, an endless resizing loop was possible so I needed to prevent that as well. This is my version of Dereck's answer that is working quite well for me:
var couponWindow = {
width: $(window).width(),
height: $(window).height(),
resizing: false
};
var $w=$(window);
$w.resize(function() {
if ($w.width() != couponWindow.width && !couponWindow.resizing) {
couponWindow.resizing = true;
window.resizeTo(couponWindow.width, $w.height());
}
couponWindow.resizing = false;
});

If need some particular element to handle resize in some particular mode, and prevent whole window from resizing use preventDefault
document.getElementById("my_element").addEventListener("wheel", (event) =>
{
if (event.ctrlKey)
event.preventDefault();
});