I'm creating a chat app, and I tried to implement autoscroll feature for it.
But it's not working on Samsung Internet(It's worked on Firefox Dev Edition(normal mode and interactive design mode) and Chrome Mobile), especially when I used the submit button on the keyboard. Here's the screenshots:
Firefox Dev Edition Interactive Design Mode Screenshot(gif)
Samsung Internet Screenshot(gif)
And here's the code:
let chatview = document.querySelector('#chatview')
if (chatview.scrollTop >= chatview.scrollHeight - chatview.clientHeight)
setTimeout(() => chatview.scrollTo(0, chatview.scrollHeight), 50)
Oh, and the reason why I added 50ms delay is to wait for element addition(powered by Vue's v-for).
Just for those who are still looking for an answer: I had the same problem with Samsung Internet version 7.4.00.70. I've tried several scroll-methods (see below). Seems to be an implementation issue.
Functions i've tested:
// Throws an error saying the method is not defined
window.scrollTo(ScrollToOptions)
// Throws an error saying the method is not defined
window.scroll(ScrollToOptions)
// Throws no error (!) but doesn't work either
window.scroll(x, y)
Links: window.scrollTo(), window.scroll(ScrollToOptions), window.scroll(x, y)
Since version 7.4 reached stable state in August 2018, i would have expected it to work.
EDIT: Working solution
I've found a solution in this thread using jQuery.animate(( properties [, duration][, easing][, complete]))
$(element).animate(
{ scrollTop: scrolling }, // Object of CSS properties
250, // Duration
'easeOutQuad', // jQuery's Easing
() => { $(element).stop(true, true); } // Callback function
);
Here element is the HTML elemente the animation is to be applied on. For detailed explanation of animate() please follow the link. The specified callback function is executed when the animation has been completed. Calling $(element).stop(true, true) (see) prevents the scrollbar of being locked. This happened in Chrome when the window was resized. In my case the resize event triggered execution of animate() and i wasn't able to scroll neither by mouse wheel nor by dragging the scrollbar.
This workaround is working on latest Firefox, Chrome, Opera, Edge, Firefox mobile, Chrome mobile, Samsung Internet Browser and Opera mobile.
I wasn't able to test it on safari. You need at least jQuery 1.8.
Related
This is the online demo suggested by MDN:
https://mdn.github.io/dom-examples/pointer-lock/
It works on desktop, but not on mobile (Chrome, Edge, FF).
Meanwhile, the pointer lock API is listed as widely supported on mobile:
https://developer.mozilla.org/en-US/docs/Web/API/Pointer_Lock_API
more demos:
Quake 3 WebGL demo
http://media.tojicode.com/q3bsp/
http://www.smartjava.org/examples/pointerlock/
I implemented it myself too, and when I used JSON.stringify(e) to read the contents of the error event, I got: '{isTrusted:true}'
UPDATE:
I used a more complex function to serialize the whole event object, so after adding the suggested by MDN event listeners:
document.addEventListener('pointerlockerror', lockError, false);
document.addEventListener('mozpointerlockerror', lockError, false);
and
function lockError(e) {
serializeEvent(e)
}
I got from the serialize function:
UPDATE #2:
I included FF as it doesn't work either, it just doesn't raise an error, while it follows pointer erratically (at high speed), without locking it and while firing the pointerlockchange event!
Scheduler Version: v.3.3.11
IE Version: 11.666 or Emulator IE11 windows 8.1 Update
Windows: 10
Jquery Version: 1.5
I'm trying to display lightbox when drag ends but it's not working on IE specific version but it works on all other browsers and other IE browser versions.
I tried binding with onDragEnd & onBeforeEventChanged, but both events are not getting triggered
But when I target IE browser to IE 9 everything, works fine , don't know what is causing the issue
Code as follow :
scheduler.attachEvent("onDragEnd", function(id, mode, e){
console.log(id);
scheduler.showLightbox(id);
});
scheduler.attachEvent("onBeforeEventChanged", function (event_object, native_event, is_new, original) {
scheduler.showLightbox(event_object.event_pid);
});
when i run this code block from console directly
scheduler.showLightbox(12235654);
lightbox gets dispalyed
I'm not sure that this issue can be solved in another way, except for installing a different version of IE. Since this is a very specific problem that is related to the browser version and not to DHTMLX Scheduler events.
I was working upon a website with a flipbook kind of jQuery effect provided by turn.js.
It was working very well on my development environment. Suddenly have found out that the mouseover effect and mouseclick has stopped working on browser Chrome V29.0.1547.66m.
It works perfectly with V26.0.1410.63 and on other browsers (Firefox).
Need to know the reason and some workaround solution for the same.
Here is the link to my webpage.
I had checked your link, I think there is some problem in turn.min.js script. Use turn.js script in place of turn.min.js it is working fine on your link.
As per issue no 399 posted on blasten/github https://github.com/blasten/turn.js/issues/399 change your turn.min.js to latest version of turn.js. This will surely solve your issue with chrome browsers' latest version on windows.
helloi was using the unminified version of turnjs and still had problems with some browsers, i read the code and discovered that mouse move events were not dispatched
i tested with 2 computers :
old Toshiba laptop with 1st-gen i7, Windows 7 Pro SP1, Opera 35.0.2066.68, Firefox 44.0.2 64Bits
brand new Intel NUC5i7RYH, Windows 8.1 Pro, same browser versions
mouse events
working properly on NUC + Firefox and Toshiba + Opera
NOT working on NUC + Opera and Toshiba + Firefox
uh ?
mouse || touch callbacks are set at line 28
touch capacity is detected at line 26
the isTouch test at line 26 returns true on some desktop browsers, which causes the mouse controls not to work
i noticed many tests provided on forum an blog posts didn't detect touch capacity properly, because they often check if touch APIs exist, which seems to be true in some Opera and Firefox browsers (i read some posts about people having the same problem with Chrome, mine works well)
i ended up using this test, which is far from perfect but does the job for now :
!(window.screenX != 0) && ('ontouchstart' in window || 'onmsgesturechange' in window);
i have no more problems, but this solution should be tested on many devices and the isTouch test must be improved
also, i got a bug in the zoom (line 90) while using latest version of jQuery, which i fixed by unchaining the two listeners as follows :
this.mousedown(zoomMethods._mousedown); // what ? chaining bug ?
this.click(zoomMethods._tap);
I am developing a web-app utilizing Application Cache, and everything is working great on desktop browsers and on Android (even very old & slow android handsets). However downloading the appcache is taking much much much longer on iOS 6 in both Safari and Chrome.
My application cache total size is a mere 2.1Mb, and I have a pretty solid 70Mbps (download) internet connection. I would expect caching to be pretty rapid.
Here are my times so far:
Desktop Chrome: <1s (similar times for Safari & Firefox)
Android 2.3.3 Stock Browser: ~4s (similar times for Chrome & Dolphin)
Android 4.2.2 (Emulated): ~7s (running inside a PhoneGap app)
iPhone 4S 6.0 Safari: 8 minutes!!! (around the same in iOS Chrome too!!)
iPad 2 6.0 Safari: as above!!!
All of these devices are using the same wifi and internet connection, and my iPhone/iPad are otherwise functioning fine (no native apps exhibiting internet speed issues, and regular websites load just fine). There just seems to be something absolutely decimating AppCache download speed under iOS.
The window.applicationCache.status throughout this time is appCache.DOWNLOADING, and I have a progress event running counting the files as they are downloaded, so I'm certain that it is not stuck elsewhere. This just appears to be the time it takes to download. What gives?
Addendum : The iPhone also runs ridiculously hot, and the battery ticks down very quickly during this operation. It seems that something is causing the CPU to run flat-out during this download.
(Note: I can't publish a link to the web-app here as we're still in private beta, but if you would need to see it before you think you'd be able to help diagnose it, email me at the address in my profile and I'll send a link to the app).
Okay, I figured it out with the help of the iOS Emulator, and Xcode Instruments to profile it. (I'm not sure if I should add my solution into the main question, or as an answer, but I thought I'd do it this way as my question is already a little cluttered).
As it turns out, it was actually some erroneous javascript causing the issue, but apparently only on iOS.
The web-app is intended to only be a single page high (no vertical scrolling, except within specific DIVs), so in addition to the usual standard JS code for hiding the address bar...
window.addEventListener("load",function() {
// Set a timeout...
setTimeout(function(){
// Hide the address bar!
window.scrollTo(0, 1);
}, 0);
});
...I had also added in the following:
$(document).scroll(
function(e){
window.scrollTo(0, 1);
});
From looking at the profile results, I was able to see that a lot of time was being spent in scrollTo, so it immediately pointed to this as the cause. Why the scroll event was being triggered so much, I have no idea (this was occurring with no touching of the screen whatsoever).
My initial fix is to throttle that code, but I am now evaluating whether or not I even need it at all. Here is the code I have that fixes it for now (using jquery-debounce, which I was already using for something else):
$(document).scroll(
$.throttle(function(e){
window.scrollTo(0, 1);
})
, 10);
The download time of the application cache is now in line with the Android times. Phew!
The code is getting itself into an infinite loop, as the initial scrollTo function call triggers the scroll event handler, which then repeatedly re-triggers itself! My best guess is that the iOS JavaScript engine handles this infinite loop differently to the other browsers' JavaScript engines.
I have the below site:
http://kelseydelo.com/
When I click the main nav links in Safari the content slides properly. However in Chrome and Firefox nothing happens when I click these (no errors in Firebug either).
I believe it used to work in FF so it seems a recent upgrade has broken it.
Anyone know what the problem could be?
you use mootools 1.2.3 which is old. in 1.2.3, mootools utlised feature detection for browser detection - and in particular, it was a problem with firefox as it relied on the following code:
if (!document.getBoxObjectFor ...)
but that method got made obsolete by mozilla. subsequently, in 1.2.5 and 1.3 mootools detection was done so it does not rely on this any more (breaking change was FF 3.6.nn or something)
on your site in FF 4.0 you can run
console.log(Browser.Engine)
and it comes back as 'unknown' - which will make any browser-specific hooks and fixes fail.
In Chrome 13 Canary, it detected webkit fine but does not work either so there must be something else -- legacy here... in other words, UPGRADE to 1.3.2 (which uses ua-sniffing) - if noobslide supports it, else go 1.2.5.1