In a react project we have an element "stickyButton" that is fixed on the bottom of the viewport on mobile. It is supposed to be displayed as long as none of some other buttons are visible. So, we try to use IntersectionObserver to check if these buttons are visible
useEffect(() => {
let stickyButton = document.getElementById("stickyButton");
function handler(entries) {
entries.forEach(function(entry) {
if (entry.isIntersecting) {
intersecting.push(entry);
} else {
intersecting.pop();
}
});
if (intersecting.length > 0) {
stickyButton.classList.add("hide");
} else {
stickyButton.classList.remove("hide");
}
}
let options = {
threshold: 0.05
};
let observer = new IntersectionObserver(handler, options);
document.querySelectorAll('div.buttons').forEach(button => observer.observe(button));
return () => observer.disconnect();
},[visibleHosts]);
Each time a button becomes visible we add it to an array "intersecting" and each time one becomes invisible again, we remove one from this array. As long as one button is visible, we hide the sticky button, when none are visible we show it.
Works fine so far, but alas, at the end of our list we have another button that loads eight more entities. This changes the variable "visibleHosts", which gets our useEffect to reinitiate. So far that's what we wanted.
But here is the problem: the new entity could very well be added by react in the viewport so it would count as visible. But since we never enter the handler function for it, it is never added to our "intersecting" array. So we suddenly have a difference between the number of elements in the array and the number of elements actually visible. And of course from there on out the sticky button no longer behaves as expected.
Is there a way to check all observed elements for visibility beyond doing it by hand (which would render the usage of IntersectionObserver pretty much moot?)
After a bit of trial and error we found the solution by not just pushing and popping the entries, but instead pushing entries.target if it is not already in the list and instead of popping filtering only entries.target from the list. That worked way better then our previous version.
Related
I am using Bootstrap 5.1.3 (in Rails). Our application consists of dynamically loaded data, that is not always the fastest to load (some complicated SQL queries / huge amounts of data to make calculations with).
We use tooltips on different elements to show extra information / indicate (click)actions. Tooltips are added like this.
On the element that should get the tooltip:
data-bs-toggle="tooltip" data-bs-placement="top" title={question.questionDescription}
In that Bootstrap file:
componentDidUpdate(previousProps, previousState)
{
// Enable all tooltips.
TooltipHelper.enableTooltips([].slice.call(document.querySelectorAll('[data-bs-toggle="tooltip"]')));
}
And then TooltipHelper:
static enableTooltips(targets)
{
var enabledTooltips = targets.map(function (target) {
return new bootstrap.Tooltip(target, { trigger: 'hover' });
});
}
The tooltips work, but don't always go away. My guess is that when a tooltip is shown (because hovering over something) and then that element (or a parent of that element) gets changed, for example the content of it, the tooltip stays there. No matter if I click somewhere of hover over other elements.
I've tried adding a delay within the enableTooltips()-function. This seems to work, but the needed delay is too big. Also, it still breaks when elements are dynamically added and content is loaded, when the page isn't reloaded.
My hacky solution:
static enableTooltips(targets)
{
setTimeout(function() {
var enabledTooltips = targets.map(function (target) {
return new bootstrap.Tooltip(target, { trigger: 'hover' });
});
}, 5000);
}
Anyone know of a solution? Thanks
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>
I've got a container that includes several icons the user can hover over and be shown a block of text next to it. I'm grabbing the blocks of text from an array and have a randomize function so that they're always shown a different block of text when revisiting the page.
I ran into an issue where every time you hover over an icon, it keeps adding more array elements, because the function gets called each time you hover over the icon. So I decided to use the one() method so the function only runs once, however that's where my real issue is. Using the one() method doesn't show ANY text, and I'm pretty sure it's due to the nested function I have.
You can test this out here: http://www.evanvolmering.com/bootstrap/docs/examples/carousel/eyeswideshut.html
In the banner a video will play, and shortly into it a little icon will appear in the bottom of left of the banner. Hovering over it will show some text. When you hover over it again it adds another array item, and so on. It works, but I don't want it to keep adding array items.
10 seconds later another icon will appear to the top right, which currently has the one() method applied to it. As you can see nothing happens when you hover over it. Not sure where to go from here.
My randomize code (which I got from another StackOverflow answer):
var numRandoms = 14;
function makeUniqueRandom() {
if (!uniqueRandoms.length) {
for (var i = 0; i < numRandoms; i++) {
uniqueRandoms.push(i);
}
}
var index = Math.floor(Math.random() * uniqueRandoms.length);
var val = uniqueRandoms[index];
uniqueRandoms.splice(index, 1);
return val;
}
My code which currently 'works' but keeps adding more array items on hover:
$('img.button1').hover(function(){
$('p.trivia1').fadeIn("slow");
$( 'p.trivia1' ).append(makeUniqueRandom());
},
function(){
$("p.trivia1").stop().fadeOut("slow");
});
My code that uses one() but doesn't do anything on hover:
$('img.button2').one("hover",function(){
$('p.trivia2').fadeIn("slow");
$( 'p.trivia2' ).append(makeUniqueRandom());
},
function(){
$("p.trivia2").stop().fadeOut("slow");
});
Use mouseenter/mouseleave instead of hover
$('img.button1').on('mouseenter',function(){
$('p.trivia1').fadeIn("slow");
$( 'p.trivia1' ).append(makeUniqueRandom());
}).on('mouseleave',function(){
$("p.trivia1").stop().fadeOut("slow");
});
I'm working with a provider and factory set up in angular, and in the factory is where I do all the heavy lifting of generating the templates, creating the instances, and doing all of the animations. The provider creates a very nifty slider menu from the left.
Problem
What's happening though, is that after the first instance of the slider menu, menu options start to double themselves. So I'll have the original 5, then 10, then 20, then 40... I have found a solution where we start with a null instance, and check if that instance is null, if it is null render the menu. So that forces it to only continuously render the initial 5, but then if we dynamically change the menu we won't ever see those changes and that is not what we want.
Fiddle
https://jsfiddle.net/Mr_Pikachu/chdbxt1h/351/
Broken Code
This is the chunk of code that I am most focused on, as it is the bit that is causing us the issue.
backdropScope.close = function(){
$animate.leave(menu).then(function(){
backdrop.remove();
//menuOpts.scope.$destroy();
// menu_rendered = null;
menu.remove();
});
}
// menustack object
$menuStack = {
'open': function(menuOpts){
menuOpts.scope.main = menuOpts.menu.main;
if(!menu_rendered) {
menu_rendered = menu_template(menuOpts.scope);
}
if(!backdropRendered) {
backdropRendered = backdropTemplate(backdropScope);
}
menuOpts.scope.$apply(function(){
$animate.enter(backdropRendered, body).then(function(){
$animate.enter(menu_rendered, body);
});
});
}
};
List of Attempted Fixes
setting menu_rendered = null in the $animate.leave() will work on the first instance, and re-render the menu properly, but then the backdrop instance won't recognize a click event
Using menuOpts.scope.$destory(), but it did absolutely nothing
Using the current solution of menu_rendered check. It is not optimal and looking for a solution that allows the use of dynamic content.
Updated Fiddle: https://jsfiddle.net/chdbxt1h/355/
I moved the angular.element calls into the body of the $menuStack.open method. The menu content does not get duplicated in repeated exposures. Presumably, this is because the DOM Node is created anew on each open, and garbage collected cleanly on leave and/or remove.
Both the background (menu-overlay) and menu are re-created on each open, so this should honor changes in the source menu data, though possibly not while the menu is open.
I am working on some tabbed navigation for my website and I have an issue I'd like to fix.
I've been scrambling my head all day and getting nowhere. Would really appreciate some help.
Here be the code: http://jsfiddle.net/EghAt/
1) Notice when you click Tab 1 and then immediately click Tab 2, Tab 1 continues to loop out all the results.
I would prefer if this stopped looping Tab 1 results and just started looping Tab 2 results.
Is this possible?
How do I achieve this?
Many thanks for any pointers
You can stop the previous animation in this function of yours, by adding the .stop(true, true) you see in this revised function:
function fadeOutItems(ele, delay) {
var $$ = $(ele), $n = $$.next();
// Toggle the active class
$$.toggleClass('active');
// Ensure the next element exists and has the correct nodeType
// of an unordered list aka "UL"
if ($n.length && $n[0].nodeName === 'UL') {
$('li', $n).each(function(i) {
// Determine whether to use a fade effect or a very quick
// sliding effect
delay ? $(this).stop(true, true).delay(i * 400).fadeToggle('slow') : $(this).stop(true, true).slideToggle('fast');
});
}
}
Since you call this on both the currently active tab and the newly active tab, this should stop any animations underway on the currently active tab.
See the jQuery doc on .stop() for details.
In looking at this code further, I believe it does what you literally asked for in your question (it stops the previous tab looping and starts the next tab), but I'm not sure that's actually what you want because it leaves the items in a tab only partially expanded. If that's what you want, then this will do that.
If that's not what you want, then the code will have to be modified a bit further to not only stop the currently running animations, but to put all the items for the old tab into the same state.
As I suspected, you actually want more than you asked for (per your most recent comments). You want the previously items to be hidden, no matter what state they were in previously. You can do that with this code where I changed the slideToggle() to a slideUp(). You can't use any form of toggle if the animation hasn't started yet because toggle will go the wrong way (it just reverses the state). Instead, when hiding you have to use a definitive animation that ends with the item not visible. You can use this code where I used slideUp() but you could pick something different if you wanted:
// A helper function that allows multiple LI elements to be either
// faded in or out or slide toggled up and down
function fadeOutItems(ele, show) {
var $$ = $(ele), $n = $$.next();
// Toggle the active class
$$.toggleClass('active');
// Ensure the next element exists and has the correct nodeType
// of an unordered list aka "UL"
if ($n.length && $n[0].nodeName === 'UL') {
$('li', $n).each(function(i) {
// Determine whether to use a fade effect or a very quick
// sliding effect
show ? $(this).stop(true, true).delay(i * 400).fadeToggle('slow') : $(this).stop(true, true).slideUp('fast');
});
}
}
You can see that in action here: http://jsfiddle.net/jfriend00/rzd3N/.
The problem is here.
$(this).delay(i * 400).fadeToggle('slow')
You are giving a fede effect to each element at once, by increasing delay.
It's not easy to stop it this way. The correct way to do this is to call a function which will only fade an element at a time. Then this function will be executed again at a given time interval (400 in your case), and fade the next element.
This way, passing a variable to the function, for example stopExecuting=true, will stop the effects.
Take a look at setInterval and setTimeout to achieve this.