First of, this looks like a chromium bug and I already submitted a bug report. It's moving slowly so I'm opening a question here mainly for a workaround solution if anyone else has come across similar or related issues.
Also, code examples are not HTML5 compliant for readability reasons. I'm just showing a reduced example.
Description
In Chrome 78 and Edge beta, when there are 2+ nested iframes with different origin and there is an overlapping element, pointerout/pointerover events are misfiring between each click inside the iframe - only when there is at least 1px movement between pointerdown and pointerup. On Chrome 77, Edge stable, Firefox and Safari these events fire only when the pointer leaves the iframe or enters it respectively, which is the correct and expected behaviour.
When removing the overlapping element, Chrome 78 behaves as expected but Edge beta doesn't (Edge beta is unaffected by the overlapping element case).
When setting the iframe origins to be similar (ex. Both localhost), it behaves as expected in both browsers.
Reproduction
Start a server (like http-server for simplicity) in a folder containing the following files
a.html
<iframe src="http://127.0.0.1:[port]/b.html"></iframe>
<div style="height: 3px;
width: 300px;
position: absolute;
top: 159px;
left: 10px;
right: 0px;
background: green;"></div>
b.html
<iframe src="http://localhost:[port]/c.html"></iframe>
c.html
<button id="btn">Click</button>
<script type="text/javascript">
var btn = document.getElementById('btn');
btn.addEventListener('pointerdown', function() { console.log('down'); });
btn.addEventListener('pointerup', function() { console.log('up'); });
btn.addEventListener('pointerover', function() { console.log('over'); });
btn.addEventListener('pointerout', function() { console.log('out'); });
btn.addEventListener('pointerleave', function() { console.log('leave'); });
</script>
Navigate to localhost/a.html click button and check console for the event logs.
Note that the iframe origins in a.html and b.html are different. With that setting if you navigate to 127.0.0.1 it behaves correctly but on localhost it doesn't.
If you move the div in a.html outside the iframes it works. (Chrome 78 only)
Question
Any potential workarounds? Ideally through JS or CSS as messing with the iframe origin and domains is not always possible nor the best solution.
Regarding overlapping div, sometimes messing with z-index works but again it's not the best solution as iframes can have overlapping elements.
Just an idea for a workaround: you could compare the coordinates in the out/leave events to the last known position inside the button element. If the coordinates are the same then ignore the out/leave events. Also you may need to handle blur event as well.
So lets say you have a down handler that sets some variables (like current position, pressed state) and also subscribes to move event.
Your move handler just updates the current position.
Your out/leave handler compares the current position to the event position. If they are equal and there was no blur event then ignore this event and return from the handler. Otherwise cancel the press, reset variables, unsubscribe from move etc.
Related
I'm trying to build a simple prototype in which I want to capture whether a user is either entering or leaving the website on desktop. Through 2 strips and a onmouseover/onmouseout I want to understand whether it's an inbound or outbound case. Hence the expected outcome is to get to the following sequences:
Outbound sequence: MouseIn: lowerStrip - MouseOut: lowerStrip - MouseIn: upperStrip - MouseOut: upperStrip
Inbound sequence: MouseIn: upperStrip - MouseOut: upperStrip - MouseIn: lowerStrip - MouseOut: lowerStrip
Unfortunately, the sequence produced by my prototype is not always the same - sometimes the 4 lines are printed to the console, sometimes only 2, and sometimes not even a single one. Seems like others have struggled with this same issue, be it in different languages and different contexts:
How do you Hover in ReactJS? - onMouseLeave not registered during fast hover over
onMouseEnter and onMouseLeave not functioning as expected
Mouseout and mouseleave not working
mouseenter and mouseleave in javascript not working
Regardless of some insights gathered from these solutions, I couldn't figure out how to actually make my solution more robuust, especially because I couldn't understand the actual root cause of the issue. Some where talking about speed being the issue, but even when scrolling over quite slow, the issue occurs.
Hence I'd like to understand what is actually causing this behaviour and what the best solution is to resolve this e.g. is it an issue in JS and could it be resolved with JS, is it an issue in JS and should it be resolved by CSS, is it another issue, ...
I attached my example below. The idea is to hover over the two strips, either coming from the bottom or the top. This should trigger the sequence mentioned earlier.
Thanks for your input.
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Template</title>
<style>
</style>
<style>
</style>
<script type='text/javascript'>
function init() {
document.getElementById('upperStrip').setAttribute('style', 'position: absolute; margin: 0 !important; top: 0px; width: ' + window.innerWidth +'px; border: 5px solid #ff0000');
document.getElementById('lowerStrip').setAttribute('style', 'position: absolute; margin: 0 !important; top: 10px; width: ' + window.innerWidth +'px; border: 5px solid #000000');
}
function onMouseIn(x) {
console.log("MouseIn: ", x.id);
}
function onMouseOut(x) {
console.log("MouseOut: ", x.id);
}
</script>
</head>
<body onload="init()">
<hr id='upperStrip' onmouseover="onMouseIn(this)" onmouseout="onMouseOut(this)">
<hr id='lowerStrip' onmouseover="onMouseIn(this)" onmouseout="onMouseOut(this)">
</body>
</html>
EDIT: 04/07/2020
Meanwhile I figured out the root cause:
"The mousemove event triggers when the mouse moves. But that doesn’t mean that every pixel leads to an event. The browser checks the mouse position from time to time. And if it notices changes then triggers the events. That means that if the visitor is moving the mouse very fast then some DOM-elements may be skipped." (https://javascript.info/mousemove-mouseover-mouseout-mouseenter-mouseleave)
"In case of fast mouse movements, intermediate elements may be ignored, but one thing we know for sure: if the pointer “officially” entered an element (mouseover event generated), then upon leaving it we always get mouseout."
Based on that, I'm now looking for a solution that is robust for my particular case. Waiting for the events seems an option, but I can also not wait 'too long' because I'm trying to register an exit intent. Also I need to at least be able to generate a onmouseover before even having a chance to capture the onmouseout.
I found a source which mentioned that: "Mouse does not report its position by every pixel it passes, there are 20ms intervals between reports. If you manage to cross your control within this interval, it will catch no mouse events at all."
Hence I should be able to capture the 4 events in ~80ms? The question is how...
I found differencies between browsers how they report computed style dimensions when browser window is zoomed. The JSBIN example is in http://jsbin.com/pilohonevo/2/. The code is as follows:
$(window).resize(function()
{
var width1=$(".class1").css("width");
$(".class1").css("width",width1);
var width2="200px";
$(".class2").css("width",width2);
var width3=$(".class3").css("width");
$("#width1").html(width1);
$("#width2").html(width2);
$("#width3").html(width3);
$("#overflow1").html($(".overflow1")[0].scrollWidth);
$("#overflow2").html($(".overflow2")[0].scrollWidth);
$("#overflow3").html($(".overflow3")[0].scrollWidth);
});
When you zoom to minimum by pressing CMD- few times and then back to 100% by pressing CMD+ few times, in Chrome (Mac Version 38.0.2125.111), you get the following values:
The white DIV 1 reports its width as 203px, although DIV 2 and 3 reports 200px. Also scrollWidth is 203, which is wrong as well. This means that you cannot use getComputedStyle or jQuerys .css() to get dimensions if you are not sure that browser window is not zoomed. And because zooming is not cancelable you can never be sure and you can never trust to those dimensions. I tested also $(elem).scrollLeft() and $(elem).scrollTop() and those are unreliable as well when zoomed.
So a workaround can be to use "raw" values, not "computed" values.
Is there a cross-browser javascript or jQuery method to get something like getUnComputedStyle() which determines dimensions using raw values from stylesheets and/or style attribute, because they are the only ones that are zoom-safe?
Determining zoom level and make corrections based on that is unreliable according to my tests, because there are browser differencies and error levels in different style properties are not consistently related to zoom level.
(Firefox Mac 33.1 and Safari Mac version 7.1 (9537.85.10.17.1) and IE 11 Win and emulated modes down to version 7 report correct values.
Opera Mac 25.0.1614.68, Safari Win 5.1.7 and the above reported Chrome report wrong values.)
I've reproduced this with Chrome 49 and JQuery 1.11, not in FF and not in Internet Explorer.
However, I believe this to be an artifact of the code as well. The only divs that show this problem are div1 and overflow1, which both use the same system of setting the width to the computed width, repeatedly. What happens is that for some zooms the computed value is 201. You set the width to 201, so for some zooms the computed value becomes 202 and so on. I got 204, for example.
In the Chrome debugger, at zoom 67%, the reported width appears as 199.981, but the values available to Javascript are integers. scrollWidth is 199 while clientWidth and offsetWidth are 200. All of the jQuery width methods return 200 (width, innerWidth, outerWidth). At zoom 33%, scrollWidth and jQuery widths all return 201, althought the debugger reported width is still 199.981.
My assertion is that the problem is a bug in Chrome and probably related to rounding.
As described here: Getting the actual, floating-point width of an element you can get the actual floating point value reported by the debugger with .getBoundingClientRect(). If you want to be completely safe, try using that one.
If I understand what you are trying to accomplish correctly (and if I don't please say so and I'll try to improve my answer), and assuming you have already managed to catch the zooming event some how (which is not a given), you could:
Clone the div you are trying to get the CSS styles from;
Append the clone to the dom in an unobtrusive way (ie, a way in which it will not cover any other elements on the document);
Remove it's style attribute (just in case it was set by other scripts or functions);
Get all the styles you need from it;
Finally, remove the clone from the dom when you are done.
This demo works for me, regardless of page zoom.
jQuery(function($) {
function getRawStyles(sel, styles) {
sel = $(sel);
var clone = sel.clone().removeAttr("style").attr("class", "cloneDiv").insertBefore(sel);
$.each(styles, function(index, style) {
console.log( style + ": " + $(clone[0]).css(style) );
});
$(".cloneDiv").remove();
}
$(document).ready(function() {
$("button", this).on("click", function() {
getRawStyles("#myDiv", ["height", "width"]);
});
});
});
#myDiv {
background: grey;
height: 50px;
width: 200px;
}
.cloneDiv {
left: -10000;
opacity: 0;
top: -10000;
position: absolute;
z-index: -1;
}
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js"></script>
<div id="myDiv" style="height:200px; width: 100px"></div>
<br/>
<button>Log Computed Styles</button>
The CSS3 resize property can be assigned to arbitrary elements. I'm looking for a way to detect such a resize on, say, divs (I don't mind it only working in Firefox at the moment):
div {
resize: horizontal;
overflow: hidden;
}
Unfortunately, the onresize event seems not to be fired on the div. How can I detect in JavaScript when such a user-instantiated resize has happened?
Edit: FWIW I had opened a bug report over at Mozilla. If you want to track it: https://bugzilla.mozilla.org/show_bug.cgi?id=701648
Resizing is like a style change. As such it can be observed with a MutationObserver. The more specific ResizeObserver is probably even better:
let observer = new ResizeObserver(function(mutations) {
console.log('mutations:', mutations);
});
let child = document.querySelector('textarea');
observer.observe(child, { attributes: true });
<textarea></textarea>
Listen to DOMAttrModified events. Got the idea from this answer, this jsFiddle appears to work in Firefox 8 (if you open the console).
Since the resize event clearly doesn't work (currently, at least), you can try one of these alternative options:
Use a combination of mousedown, mousemove and/or mouseup to tell whether the div is being / has been resized. If you want really fine-grained control you can check in every mousemove event how much / if the div has been resized. If you don't need that, you can simply not use mousemove at all and just measure the div in mousedown and mouseup and figure out if it was resized in the latter.
Poll every 200ms or so (depending on your needs) and compare the current size with the last known size. See setTimeout().
You can use the ResizeSensor class of the css-element-queries polyfill from
https://github.com/marcj/css-element-queries
It allows you to call a javascript function on size changes for all types of elements, not only for window. It sets up a real sensor, not a javascript setTimeout poll.
Use it like this:
new ResizeSensor($('#myelement'), function() {
console.log("myelement's size has changed");
});
Supported browsers are: all incl. IE6+.
This seemed to work pretty well for me:
$("body").on('mousedown mousemove', ".resizeItem", function () {
console.log($(this).height());
})
"Use a combination of mousedown, mousemove and/or mouseup"
as per Felixs answer.
Especially useful when combining a custom search result panel with Dev Extremes Scroll View and you want full control over it.
$("body").on('mousedown mousemove', ".scrollContainer", function () {
var h = $(this).height() - 20;
$(".scrollArea").dxScrollView('instance').option('height', h);
});
According to this site it only works in internet explorer 9.
Try this fiddle: http://jsfiddle.net/maniator/3Zva3/
I am trying to position an span element (let us call it "the tooltip span") relative to a input field. To do this, I am wrapping the tooltip span and the input field in another span element (let's call it "the wrapper span") that has position: relative. Then I set position: absolute on tooltip span. This makes the tooltip span position itself relative to the wrapper span but not being part of the page flow - not taking up any space. This is exactly what I want.
Then, using javascript, I set the position of the tooltip relative to the position of the input element. Since the input element can be shaped differently on different pages (script should be globablly applicable), I am using its offsetTop and offsetLeft properties to calculate its position relative to the wrapper span.
However, I am noticing inconsistencies between browsers here. In Firefox, IE6, 7, 8, it works as expected. But in Chrome and Safari the reported offsetTop seems, well, incorrect.
To prove this, I created the test page below:
<html>
<head>
<style type="text/css">
span { font-size: 8px; position: relative; top: 0; left: 0; border: 1px solid red }
</style>
</head>
<body>
<span id="wrapper">
<input id="foo" name="foo" type="text">
</span>
<script type="text/javascript">
document.write("<br>Offset parent: " + document.getElementById("foo").offsetParent.id);
document.write("<br>Offset top: " + document.getElementById("foo").offsetTop);
</script>
</body>
</html>
and loaded it in Firefox and Chrome. Both browser report the wrapper span as its offsetParent, but for Firefox the offsetTop is -8 and for Chrome it is 2. Visually the page renders the same in both browsers.
This gives me a headache, because I cannot just hack in a different offset that I always apply when someone is using Chrome, because if I change the font size, the offsetTop will not change, and my script will break.
Is this a bug? Can I solve this differently?
You Can try using
$(window).load
instead of
$(document).ready
because Explorer and Chrome sets proper offsets only after images have been fully loaded.
I've been having the same problem as you and I realized that (in my case) the thing that was messing up the offset().top value in chrome, was having one or more images without the "height" attribute above the element.
Before
<img src="/images/foo.jpg" />
offset.top() was 100 in Chrome
offset.top() was 150 in Firefox and IE7 (beleive or not, it worked just fine in IE!)
After
<img src="/images/foo.jpg" height="50" width="50" />
offset.top() is 150 in both Firefox, IE7, AND CHROME.
Notice the the difference was 50px, which is actually the same as the image height.
Since I was developing a JQuery plugin, i tryed to collect all the images that had their width and height attributes undefined, and manually setting their size with .width() and .height(), but it didn't work, because Chrome returned 0 for both functions. So, i guess the problem with offset.top() actually relies on that. If JQuery is triying to get te offset.top() value by accumulating the "above" element's height, and one of those elements it's an image with no specified height, "0" will be added to that sum, and therefore the top value will be missing those "ignored" heights.
PS: Sorry for my english, it's been a long time since i wrote such a long text in this language!
Use jQuery. DOM differences between browsers is one of the things it excels at.
Put you code into a window.onload function. I recall having issues when attempting to work with the dom directly from a <script> during page load in firefox, and webkit tends to be slightly more willing to give a sane DOM at such points.
This is just based on prior issues i've encountered, i'm not sure if it's applicable to your case.
I ran into the same problem, and jQuery's position() function was reporting the same as the offset() function. Ultimately it turns out that even waiting for the document to be ready didn't work for me. I had to check offset() later in the flow (in my case, in my handler that is fired on a window.scroll event).
When I try this test code below, on page load, I get different figures for Firefox + Chrome. Once it loads, however, I can press 'd' and I get the same figure for both browsers.
// this produced different results on Chrome + Firefox (Chrome was wrong!)
$(document).ready(function () {
var x = $('#some-div-on-your-page').position().top;
alert("On load, offset is "+x); // Chrome + Firefox report diff figures
$(window).keydown(function(e, r) {
k = e ? e.keyCode : event.keyCode;
if(k == 68) { // press 'd'
var x = $('#some-div-on-your-page').position().top;
alert("Now the offset is "+x); // ...but this is consistent
}
});
}
Hope this helps.
I was experiencing the same problem, and tried adding to my function
$(document).ready(function(){});
and it worked in both Chrome and Firefox
If you get "0" in chrome, see if you are targeting an empty element like "a". It needs to wrap something in order to return the correct offset.
It could be related to the different border/margin values for the HTML and body elements that browsers set by default.
I want to hide the cursor when showing a webpage that is meant to display information in a building hall. It doesn't have to be interactive at all. I tried changing the cursor property and using a transparent cursor image but it didn't solve my problem.
Does anybody know if this can be done? I suppose this can be thought of as a security threat for a user that can't know what he is clicking on, so I'm not very optimistic... Thank you!
With CSS:
selector { cursor: none; }
An example:
<div class="nocursor">
Some stuff
</div>
<style type="text/css">
.nocursor { cursor:none; }
</style>
To set this on an element in Javascript, you can use the style property:
<div id="nocursor"><!-- some stuff --></div>
<script type="text/javascript">
document.getElementById('nocursor').style.cursor = 'none';
</script>
If you want to set this on the whole body:
<script type="text/javascript">
document.body.style.cursor = 'none';
</script>
Make sure you really want to hide the cursor, though. It can really annoy people.
Pointer Lock API
While the cursor: none CSS solution is definitely a solid and easy workaround, if your actual goal is to remove the default cursor while your web application is being used, or implement your own interpretation of raw mouse movement (for FPS games, for example), you might want to consider using the Pointer Lock API instead.
You can use requestPointerLock on an element to remove the cursor, and redirect all mousemove events to that element (which you may or may not handle):
document.body.requestPointerLock();
To release the lock, you can use exitPointerLock:
document.exitPointerLock();
Additional notes
No cursor, for real
This is a very powerful API call. It not only renders your cursor invisible, but it actually removes your operating system's native cursor. You won't be able to select text, or do anything with your mouse (except listening to some mouse events in your code) until the pointer lock is released (either by using exitPointerLock or pressing ESC in some browsers).
That is, you cannot leave the window with your cursor for it to show again, as there is no cursor.
Restrictions
As mentioned above, this is a very powerful API call, and is thus only allowed to be made in response to some direct user-interaction on the web, such as a click; for example:
document.addEventListener("click", function () {
document.body.requestPointerLock();
});
Also, requestPointerLock won't work from a sandboxed iframe unless the allow-pointer-lock permission is set.
User-notifications
Some browsers will prompt the user for a confirmation before the lock is engaged, some will simply display a message. This means pointer lock might not activate right away after the call. However, the actual activation of pointer locking can be listened to by listening to the pointerchange event on the element on which requestPointerLock was called:
document.body.addEventListener("pointerlockchange", function () {
if (document.pointerLockElement === document.body) {
// Pointer is now locked to <body>.
}
});
Most browsers will only display the message once, but Firefox will occasionally spam the message on every single call. AFAIK, this can only be worked around by user-settings, see Disable pointer-lock notification in Firefox.
Listening to raw mouse movement
The Pointer Lock API not only removes the mouse, but instead redirects raw mouse movement data to the element requestPointerLock was called on. This can be listened to simply by using the mousemove event, then accessing the movementX and movementY properties on the event object:
document.body.addEventListener("mousemove", function (e) {
console.log("Moved by " + e.movementX + ", " + e.movementY);
});
If you want to hide the cursor in the entire webpage, using body will not work unless it covers the entire visible page, which is not always the case. To make sure the cursor is hidden everywhere in the page, use:
document.documentElement.style.cursor = 'none';
To reenable it:
document.documentElement.style.cursor = 'auto';
The analogue with static CSS notation is html {cursor:none} (or, depending on what exactly you want * {cursor:none} / :root {cursor:none}).
I did it with transparent *.cur 1px to 1px, but it looks like small dot. :( I think it's the best cross-browser thing that I can do.
CSS2.1 has no value 'none' for 'cursor' property - it was added in CSS3. Thats why it's workable not everywhere.
If you want to do it in CSS:
#ID { cursor: none !important; }
For whole html document try this
html * {cursor:none}
Or if some css overwrite your cursor: none use !important
html * {cursor:none!important}