Three.JS - Scrolling issues in firefox - javascript

I am not sure if anyone else is having this problem or not with three.js. I have a simple demo of a cube that will spin with a varying rotational velocity (arrow keys, mouse, or touch input). Everything seems to work fantastic in the Chrome browser. At work I hopped on the iMac, the textures seem to be splicing and not mapped to my geometry correctly in Safari.
I moved over to the Firefox browser on the mac and everything works, and the frame rate is decent. It just seems that for some reason when the cube gets rotated at certain angles the renderer jumps and the onscreen hud moves up and you can't see the title at the top and the stats widget moves up from the bottom of the screen. It also seems that my cube's y position jumps up at the same time. I seem to have the same problem in android on some of the mobile browsers. I was wondering if anyone has had similar issues in Firefox (on Mac?) or in mobile browsers with the rendering suddenly jumping, moving the onscreen hud, etc
EDIT: I have figured out the problem. I still do not have an ideal solution. I created a copy of my demo and tried commenting out my keyboard handling code and to my surprise the issue still existed. Apparently firefox is scrolling the window slightly up and down and the keyboard handler included in the THREEx library does not disable the default behavior of the up and down arrow keys in Firefox. In chrome there is no room to scroll my window and I simply make my renderer the size of the window. I do not see why firefox is scrolling.

I experiment the same problems on Firefox in Mac on your example.
The jumps on the rendering are due the garbage collector (poorly implemented on Firefox). You are allocating memory on each "animate" function.
Instead of creating new Vector3/Matrix4 for your rotation, use global variables, so you just create those objects once.
Besides, instead of using KeyboardState, and executing those 'State' functions on each animate call, you should use a KeyboardListener, which will execute your code just when something changes (and not all the time).
You should take a look to this example: http://mrdoob.github.com/three.js/examples/canvas_geometry_cube.html

The problem was that for some reason in Firefox (not Chrome) there is room to scroll even though the renderer is set to the window size, so Firefox was scrolling when using the arrow keys. To fix this, I edited two functions in THREEx.KeyboardState.js adding a preventDefault() to prevent the arrow keys from scrolling.
Here are the needed edits:
this._onKeyDown = function(event){
event.preventDefault();
self._onKeyChange(event, true);
};
this._onKeyUp = function(event){
event.preventDefault();
self._onKeyChange(event, false);
};

Related

Drag and drop issue in Chrome related to Windows scale (125%)

I have an issue with drag and drop on Chrome (v69.0.3497.100). Specifically, some of the drag and drop events are getting fired when Windows scaling is other than 100% even though they shouldn't be firing.
Check out stackblitz example, and try to drag "blue" rectangle over itself (just drag, move a little bit downwards and drop). If Windows scaling is set to 100% (browser zoom is 100% as well) then one event is fired (dragEnter) as expected (check the console). But, if Windows scaling is set to 125% (but browser zoom is still 100%) then three events are fired (two dragEnter and one dragLeave), and I expected only one event to be fired since the element was dragged and dropped on itself (as it was the case with 100% scale level).
It could be that since this is Windows zoom (and not browser's zoom) the left ("lightred") rectangle is larger that it appears, and it goes below right rectangle, and events are propagated to it, although I couldn't prove that since all elements have correct size in the inspector.
This doesn't seem to be happening in latest Firefox, IE or Edge.
Does anyone know why is this happening and how to fix it?
The more I look at this problem, the more it seems the Chromium issue. Some days ago I posted a question, then I wanted to set up a bounty for it, and then I found your one, and I believe they are interrelated: Subpixel scroll issue, can't set scrollTop properly on Chrome 69.
There are some bug reports in Chromium issue tracker related to scale-rounding problem: link 1, link 2... I also created my own bug: link 3. There should be more information but it takes too much time to research. I think we may join efforts and draw more attention to the problem, and for example if it's Chromium responsibility, to help them with clarification and prioritisation.
I have the same problem with Version 76.0.3809.100 (64-Bit).
And I offset the image to compensate for the strange offset that I get in your stackbliz example too.
But with scaling 200% I need to multiply my calculated dragImage offset by 4 !!!
On 300% it's at 9
On 350% it's at 12.25
Do you see the pattern ???!
I'm afraid of my hack/fix for this problem. Not sure if it's just on windows, if it's just desktop. But for now I guess I will have to do window.devicePixelRatio^2 so I can continue my work.
There are instances where a website has drag-and-drop features that will not work inside the Google Chrome browser.
Fixing Drag-and-Drop
Enter the following into the Google Chrome Top search bar.
Chrome Flags: chrome://flags/
Type Touch into the search bar and set the following options to Enabled.

Android Native Browser duplicating HTML5 canvas (fine in chrome)

This is a weird issue that I am only experiencing on a Native browser on Samsung Galaxy Tab 2 and Galaxy S2 in the native browser.
This has also been tested on other android phones and tablets such as the Nexus 7 & Galaxy S4 but their native browser is chrome, so it appears fine. This issue is also not present on any IOS browsers, Windows Desktop browsers or Mac Desktop browsers.
It's almost asif the webpage is loaded twice ontop of itself!
As there is a duplicate canvas element, that updates as the main canvas does.
Here it appears asthough it only happens when rotated in landscape mode, but I beleive that in portrait mode, the canvas' are perfectly aligned over the top.
What is even weirder, the menu button that you see is a toggle button, tap to open menu, tap to close menu. On this device when you tap it, it opens and closes instantly. the same happens for the mute button toggle.
I'm completely at a loss.
I have done some javascript debugging throwing in a few alerts here and there, and the initialisation functions that create references to the canvas and so on are only called once.
I have read and heard about hardware acceleration causing issues, but solutions i've potentially found are only relative to building native apps! not HTML5 Canvas webpages.
Any insight on this could be would be great!
Thanks in advance.
--EDIT
I also put in this test alert(document.getElementsByTagName('canvas').length); to see if there was 2 canvas in the DOM but it returns 1!
I ran into this same issue. I was able to fix this by running the following code after making a change to my canvas:
// If Samsung android browser is detected
if (window.navigator && window.navigator.userAgent.indexOf('534.30') > 0) {
// Tweak the canvas opacity, causing it to redraw
$('canvas').css('opacity', '0.99');
// Set the canvas opacity back to normal after 5ms
setTimeout(function() {
$('canvas').css('opacity', '1');
}, 5);
}
By tweaking the opacity, this forced the canvas to redraw and removed the duplicate shapes. It's a dumb fix but it works. Hopefully this helps someone.
Also you may look at this collections of such tips: http://slash-system.com/en/how-to-fix-android-html5-canvas-issues/
For double canvas issue there is a bug logged https://code.google.com/p/android/issues/detail?id=35474 you may want to check suggested solutions.
In my case this issue appeared only if I had Force GPU rendering enabled.
Issue usually appears if you have some parent element for canvas that has CSS overflow: hidden
remove overflow property from all canvas parents,probably we don’t need this property on touch devices:
$("canvas").parents("*").css("overflow", "visible");
It is well explained at http://slash-system.com/en/how-to-fix-android-html5-canvas-issues/

Rendering bug in Google Chrome at certain window widths

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.

Hammer.js - Rotation in Internet Explorer 10

I'm having some trouble with the hammer.js-touch-framework, to be more precise, the rotation-trigger. My code is pretty minimalistic, as you can see in this jsfiddle (I'm using jquery.hammer.js from the official hammer.js-website):
http://jsfiddle.net/kgEFs/
My main problem is, that rotation and pinch both are not triggered, only tap gets fired.
I know, other browsers might be better for web-development, but I'm interested in how I can make my object rotate, even in Internet Explorer.
Tapping on the <div> with MSIE 10 triggers the tapping event and even could rotate the object, if there was a value (you can check by simply changing e.rotation to 10). I already got the rotation-event once, but I can't reproduce how I achieved it.
Any ideas?

Mouse X/Y detection within Flash stage not working Moz & Webkit on PC

I am trying in vain to get this Flash based navigational item working in FF and Chrome on PC. It's all good on Mac and it's just fine using IE 7 or 8 on PC.
The nav item consists of a ball that "follows" the cursor in relation to where it is on the page. JS is used to gather the X/Y info from off the Flash stage and create vars to be used by the Flash movie to move the "orb" in relation to the cursor position. For some reason, FF and Chrome on PC fall short here.
I've tried everything from setting the Flash movie to "opaque" and positioning a transparent DIV over it, all to no avail.
Any thoughts on this? Has anyone encountered something like this?
Example here:
http://anthrograph.com/yarbyarb/thang/
We were given the compiled SWF with the listeners setup, but as of now, I do not have access to the FLA to make changes.
Thank you!
i tried in chrome and firefox, when mouse is on html part, positioning is working, while mouse is on flash it is not working.
if i understand, easiest solution is for window mode, you should make a displayObject, a sprite and set it to belove everything else with alpha = 0, with this you can set window mode anything you like.
other then, you should add Listener to MouseLeave and MouseMove to detect when listen javascript or actionscript.
there is another error, you should mask your buttons that right side. they are under other graphic but mouse_over is working when it should not. For this use ROLL_OVER instead of MOUSE_OVER.

Categories