I am trying to implement a chat application, more precisely a scroll behavior for chat application. I think it's best described with a gif.
https://i.imgur.com/NnpMeOx.gif
As you can see, I want to support a few key features:
Scrolling is reversed so on page load, the messages start on the bottom along with the scrollbar
Chat is scrolled to the bottom when user types in a message. (this is easy, no need to pay attention to this part)
If new messages appears (pushed by websocket in real life) it shouldn't disrupt the existing scroll position, unless it's already at the bottom. Then it should scroll to reveal the message automatically.
So far I've implemented 2 solutions:
a) Display flex and flex-direction column-reverse on the scrollable element. This works beautifully out of a box, but only on chrome :( IE (and Edge) as well as firefox just ignores this totally. NOT A GOOD SOLUTION
b) I flipped the container with transform: scaleY(-1) then I reversed the messages and fliped every one of those with the same transform. The main obvious problem here is the scroll (mouse wheel and arrows) is reversed. I sort of fixed it, didn't manage smooth scroll (sucks) but yet again, Edge (and probably IE) just shows scrollbar as disabled. NOT A GOOD SOLUTION
I am really hoping to find somebody who can point me in the right direction because so far, my efforts while logically ok totally failed browser compatibility.
The code is on https://github.com/PeterKottas/react-bell-chat, it's react but tbh, that doesn't matter much as this seems more like a general web dev exercise.
P.S.: I can't use jQuery, hope that's fair. So either css or plain javascript. Like I've said, this doesn't have much to do with react
Well I got no replies and managed to fix it myself so I'll accept this in case it helps somebody in the future.
3rd and final solution:
I kept the direction of scrolling and didn't do any reversing at all. Instead I hooked into onScroll and wheel event, created a few callbacks and managed to mimic the behavior perfectly. You can find more details in the code on https://github.com/PeterKottas/react-bell-chat.
Related
I am trying out this new implementation where I am updating some div's bottom/top value to emulate fixed position using javascript with scroll event. The problem is while scrolling the div's are getting a fixed position but moving little bit up/down depending on scroll direction. Had to do it this way as I used transform scale. So CSS position fixed doesn't work. Any optimization advice will be very helpful.
the code is here --> Alternative of position fixed using JavaScript shows weird behavior on window resize
If you check my page on desktop/laptop you can experience that. It depends on a lot of variables like how powerful the device is, browser to browser. I am hoping that if anyone has access to MAC OS on safari and chrome or Windows chrome or any desktop/laptop with a decent browser on it may check the user experience and leave a comment about how laggy jittery is it? Is it like okay or bad?
the webpage link --> https://elomymelo.com/soundcore-motion-boom-plus.html
All you need to do is, scroll down half of my page clicking the link above on desktop/laptop. The right side content should get fixed. But may have jittery behavior on scroll. And please leave a comment about how bad is the experience?
Thanks for your time. This will help me a lot to figure out if I should implement it on the other pages or not. Any optimization advice will be very helpful.
I am implementing a navigation with anchors that trigger some Javascript to scroll to a specified element, testing it on iOS (Iphone 4) for now.
This is not a new topic and I have done a lot of research before I decided to re-open this question, for no avail. However, my setup also differs a bit from the numerous others in that I first trigger a transition on the navigation horizontally and then the smooth-scroll afterwards. I am wondering if the combination might raise that "buggy" behavior. What make me not really believe this is the fact that waiting for the transition to finish does not resolve the problem (neither using a callback function, nor utilizing window.setTimeout).
Using .scrollTop simply make the browser jump to the element. The transition of the navigation however is smooth.
Using .animate, the transition of the navigation is very laggy. When I apply a very slow animation, it "only" laggs until the transition of the navigation has finished (or some milliseconds after that), whereas the last part of the scroll is quite smooth (this gives me some hope).
The .translate3d CSS option worked fine, but the page is "cut" so that I cannot scroll back after the transition has finished. This is more of a solution for full screen pages I guess.
I do not want to know how to implement an anchor that triggers scrolling, I am asking if someone knows a smooth way to implement scrolling (in my case for iOS). Meaning, I realise that I could have written the JS-Function more generic, but this is only test-code for now.
I have not tested this on android as my target device is iOS, but if this is a known issue only for iOS (e.g. it is working on android) I would be happy if you tell me.
JavaScript / jQuery:
$('#my-link').click(function (event) {
scrollTo('element'); /* hand crafted for now */
event.preventDefault();
});
function scrollTo (element) {
navToggle(); /* This toggles classes on various elements, triggering the respective element's transition */
$('html, body').animate({
'scrollTop': $('#'+element).offset().top /* I deleted the callback (on navToggle) and setTimeout code as it did not make a huge difference to the result */
}, 666);
}
HTML:
<!-- typed out by hand, if there are minor errors they are not related to the issue -->
<a href='#element' id='my-link'>Click to scroll</a>
...
<div id='element'>...</div>
Providing that code is actually just part of the etiquette as I dont look for concrete improvement on what I have written. However, this works like a charme on desktop browsers and if it helps some of you, the better. Also check out this question on how to implement anchor scrolling as it delivers great answers for desktop browsers!
It is late (or early) and my brain is a mess, but I hope I made my question clear (If not I will come back to edit it.): Is there a way to make a mobile browser (e.g. iOS' Safari) smooth scroll like a charme? If already solved, please point me in the right direction.
Thank's a lot and happy coding!
My users and I are running into a rendering glitch in Chrome only (on both Windows and Mac) where an overlaid div that I'm using for on-hover tooltip-style "popouts"(see first image below) does not get rendered properly in certain cases (see second image below). In all other browsers I've tested, it works as expected.
Here's how the hover popouts are supposed to look (and what happens in Firefox, Safari, IE):
Here's what happens in Chrome:
You can see it in action on this site if you look at May 24 using a browser window width of ~ 1200px (significnatly wider or narrower windows do not seem to work). The glitch only affects the popouts in the bottom right of the menu that are popping left, e.g. those on May 24. Hovers using the same exact mechanism higher up in the page work just fine. Glitched popouts are invisible (except for part of the carat), but if you click on the link to lock the popout in place and then hold left click while moving your mouse around as if to "select text" in the area where the popout should be, it will then render partially. Also if I open dev tools and try to select the popout, it will render just fine at that point.
I've been looking at this all day and trying different work arounds with opacity, z-index, etc. and getting nowhere. Does this glitch ring any bells for anyone? Is there a way to force Chrome to render the div, once its been positioned and unhidden? I'm fine with any work-around or hack.
I use a custom (and fairly complicated) jquery plugin for popouts. If it would be helpful to see the non-minified javascript for the plugin, I can post or provide a link to that, but general guidance that leads me to a work around will be sufficient to be accepted as an answer.
Edit: My Browser Build: 26.0.1410.65
(Per my comments)
This does indeed seem to be a bug in Chrome, though without a smaller test case to reproduce it, it could be very hard to track down. You may want to report it to the Chrome team with as much information as possible.
In support of my "it's a bug" assertion:
The hidden/clipped elements become visible when they are selected.
The elements underneath the hidden/clipped elements are not clickable.
This indicates that z-index and height is correct.
It only happens under very specific circumstances; the rest of the items with the same style work fine. The same item may work fine at a slightly bigger/smaller screen width.
Applying a 3D transform fixes it.
The problem goes away when I apply a CSS transform such as scale3d or translate3d. I imagine this is because certain CSS properties cause the browser to switch to GPU acceleration.
In this case, switching to the fast path for rendering seems to alter the drawing sequence enough to fix the problem.
Super hacky but this fixes it for me:
$('.drop-link.food').on('hover',function() {
$('.tool-tip').css('overflow', 'hidden').height();
$('.tool-tip').css('overflow', 'auto');
});
Obviously this isn't a "good" solution, and even remaining hacky you could probably optimize it to only force the redraw on the tooltip it needs to, but hopefully it helps...
Another clue:
$('.drop-link').on('hover',function() {
$(this).siblings('.tool-tip').css('display','block');
});
This won't fix it right away, but it seems like if this is there, once you've hovered on something, it will work the next time you hover on it.
Not sure if this helps with your situation, but over the last couple of days I've started to notice that certain site elements on Facebook and Weight Watchers no longer show up. Specifically it seems to be affecting items that (I believe) to be controlled by or dependent on Javascript. When I call up these sites in Firefox and Safari they work as expected.
I'm currently fighting a very frustrating bug on Safari, and I'm not sure where else to turn.
It seems most elements (but not all, and I can't discern the differentiating factor) that will trigger a focus event will cause all elements on the page that are transitioned or animated to jump ~2px to the top and left. And this only occurs on the first focus event after the page loads.
It's a little annoying to see the bug, as it's in the logged-in portion of droplr.com, and I have been completely unable to distill down a simpler case on JSFiddle.
If you have/create an account and log-in, click on this edit icon for a drop:
You'll see that on the first focus of the page, things jitter. Here's the timeline when there's a single drop on the page and I trigger focus on an offending element:
With more drops, it's just more of the same, but it seems to max out around 40 paints. And the profiler doesn't suggest anything nefarious. Just a trip through jQuery internals.
If instead of laying elements out via a translate3d or matix3d, I simply use top and left, this bug goes away. After hours and hours of debugging this, I'm at a complete loss.
Hoping someone has seen something similar, could take a look, or could give me advice on debugging next steps.
Thanks so much!
Update: Dave Desandro suggested it was the 3d acceleration kicking in, so I tried it out with a translate instead, and sure enough, that did not cause the jitter. I have no idea why the hardware acceleration would be firing up with a focus event though, and only once.
I've tried setting a transformZ of 0 on page load to go ahead and ramp-up the hardware, but no luck there, either. Any more ideas are welcomed.
I've had this issue a while back and honestly I don't remember what exactly was the cause but here are some of the steps I followed:
Check that you don't have hide() and show() for the same element in the next line or vice versa.
Example:
el.show()
el.hide()
Change Custom fonts to "Arial"
For the elements you don't want focus events add this code at the bottom of your scripts:
noFocusElem.off('focus');
This will make sure to remove any focus handlers you might have added by mistake
Finally place your css before any scripts. It's a know fact that adding css rules after an inline style has been applied may cause jitter especially if you're using line-hieght property
Hope this helps :)
I've had this happen when using custom font kits. Could this be the issue? Some events cause custom fonts to re-draw, which can cause a ever so slight "jitter" in page display.
Sometimes, manually setting heights and widths on all the parent HTML elements can reduce the flicker.
I know this question was posted a while ago and this is a bit of a long shot but here goes:
Maybe as a starting point go back to chrome and look at the composite layering:
Hit this into the address bar:
about:flags
You will be able to enable composite borders from within there. The red borders generally indicate a rendering issue:
http://www.chromium.org/developers/design-documents/gpu-accelerated-compositing-in-chrome
What I have found from time to time is that although there are rendering issues in Chrome the browser copes pretty well with hiding them from me. In other webkit based browsers however the result can be more noticable (i.e. android).
I've also seen flickering occur when z-indexes are being used in conjunction with content that is being transformed.
Either way it would be great to know how you resolved this issue (if you did). Post an answer to your own question perhaps?
A way to avoid spending time fixing load time twitches; you could set the page to hidden then make elements visible with the load. If your page is slow to load, you may want to have a spinner default to visible, then have load hide it. Then you could come back to the issue when you have nothing better to do.
Just my 2c worth.
The first thing I would try:
First in chrome, whack in 'about:flags' (yes I know you're not using Chrome). Find the 'Composited render layer borders' and turn it on. Once this feature is switched on you'll get a rough idea of what is being rendered/hardware accelerated.
See: http://www.chromium.org/developers/design-documents/gpu-accelerated-compositing-in-chrome
and look for any rendering problems. These are normally caused by z-indexes. Play around with any z-indexes and hide/show certain elements until the rendering issues are resolved. Then work from there. translate-z hacks and opacity can also cause problems.
From experience I've found rendering problems in other webkit browsers can be diagnosed using chrome. Flickering is a common occurrence on the stock android browser.
Secondly: take a look at the focus event itself and try things like preventing the default behaviour. Seems like a long shot to me but give it a go.
I haven't tested this, so I will be very surprised if it works... but here's an idea:
$(document).ready(function() {
$(document).focus(function(e) {
e.preventDefault();
});
$(document).click(function() {
$(document).unbind();
});
});
I've been running into the same issue recently and found something that fixed it in my case.
Check for anything that's hidden offscreen like:
text-indent: -9999px;
left: -9999px;
Removing any instance of these from the 3d accelerated elements (including children) stopped the content jump on focus for me.
I am working on a site to the specification of a designer who loves to put styled scroll bars on the page (not the main scroll bar on the right, but for various fixed-height divs on the page, when the content overflows).
I'm not asking if this practice is "right" or not, and I know it's generally accepted to be a bad idea in terms of user-experience, but that doesn't change what the client is now expecting to see on their site.
Does anyone know of any relatively bug free, cross browser methods for doing this. Examples I've seen so far include Skinned HTML Scrollbar, Ajaxian Webkit, and jScrollPane, but I'd like to hear from anyone who has achieved this functionality in the past before I implement one of these.
Thanks in advance.
I've used jQuery in the past when a client and their designer insisted in having customised scroll-bars. It's quite easy to stick a div on the side of a box and make it draggable between limits (and interpret the position to set the scroll offset).
But you also have to consider what happens if they want to scroll using the mousewheel, or middle-click. They're not blockers but you'll have to write listeners to update the scroll-bar position too.
Whether or not you should do it is a completely different question. You should certainly not just rely on your custom JS. Make the JS disable the scrollbar and paint all your controls using JS. If you don't do this, people with JS disabled/blocked won't be able to use your site.