An issue in the Chrome browser (https://code.google.com/p/chromium/issues/detail?id=170631) is causing quite a few issues with functionality that I'm building for a website at the moment. In the application if an onmousemove event is triggered simultaneously as a onmousedown event it appends a class that disables accidental link following since the user is dragging DOM elements. However, if an onmousedown event is fired and there is no movement (essentially a single click) it will follow the link.
This works flawlessly on everything except Chrome, since it incorrectly interprets an onmousedown event as an onmousemove event (occurs with both JavaScript & jQuery). I thought about adding a timer to determine how long the user has held the mouse button down to distinguish the difference between click and drag, but this seems like an inefficient and potentially error prone option. Any thoughts on how I could setup a work around until Chrome fixes this bug would be much appreciated.
Related
I have a webapp with an inner-pane inside an outer-window.
The user can zoom-in in the inner-pane via 2-finger pinch, without zooming-in the outer-window.
On Chrome on Android, the app works as expected.
But Safari on iOS device (iPad), zoomimg-in inside the inner pane, actually zooms-in the entire window, which is not the intended behaviour.
I read here that iphone/ipad can trigger unexpected events.
I want to find this event.
I remote-debug the webapp iOS Safari by connecting the iPad to a Macbook and debugging via Safari.
In Safari Web Inspector, Sources tab, Breakpoints section, I added All Events.
When I touch the pane, the code breaks as expected on the ontouchstart event, which is not the offending event.
I can add specific events to break on, by name.
But because I don't know which is the offending events, I want to break on all events except the ontouchstart event.
Is it possible to stop on all events in Safari except specified events?
Thanks
I did not find out if it is possible, to break on all events excluding specific event(s).
I recently found this link which comprehensively explains various breakpoint options in Safari.
The author of the link graciously answered my question:
Currently there is no way to exclude specific events.
In your scenario, is it really necessary to add listeners for all events, or is it a known list of specific events (e.g. all touch and mouse)?
If it's the latter, I'd suggest just adding a global event listener breakpoint for each event other than the one event you want to exclude.
Another option might be to configure an All Events global event listener breakpoint with a condition of something like window.event.type !== "..."
(note that this will only work in Safari Technology Preview 114 or newer).
p.s.
The reason for my question was an upstream offending event listener.
Because the problem was in an event listener that is upstream to the target event, it wouldn't have helped to break on all events excluding specific event(s).
I ended-up solving my original problem by applying addEventListener with passive = false, and using preventDefault() to prevent from triggering the upstream event handlers in the bubbling stage.
For whatever reason, natively in Chrome, mousemove events that immediately follow a mousedown event are not firing or are simply ignored altogether for a small period of time (500-1000ms?) following the mousedown event.
Strange thing is that this issue is nonexistent on codepen (on Chrome too) and the code is the exact same... There's also no issues with Firefox, Edge, etc, only natively on Chrome.
Here is a codepen nonetheless. Test it for yourself.
Copy and paste this code into actual .html, .css, and .js files, and then run it in the browser directly, you'll notice that paper.onmousemove does not fire or register immediately after a window.resize event for a very small period of time.
None of this makes any sense!
Anybody have any idea what's going on? Why would it work fine in codepen (and every other browser), yet not directly in the browser?!
I have found one issue with the codepen version, which produces a very similar bug (but involves a couple extra steps in the beginning).
Create an element by dragging your mouse on the white area
Select that element by clicking it
Drag that element anywhere on the page
Resize the browser and immediately try to create another element by dragging
However, on codepen mousedown isn't firing in this case, whereas mousemove is not firing if viewed directly in the browser. Again, there is a discrepancy, which incredibly bizarre.
Update
It turns out it only happens when the developer console is open, which is why it was not happening in codepen.
This seems to be some weirdness with Chrome DevTools. The bug you describe seems to only occur when DevTools is open. It goes away when you close DevTools. It may just be a weird coincidence, but it starts logging out mousemove events immediately when the resolution label in the top right goes away.
That being said, you have a combination of onmousemove and addEventListener going on. For instance you have both
paper.addEventListener('mouseup', checkMouseUp)
and
paper.onmouseup = function(event) {}
I'm not sure if it's the cause of the DevTools issue, but this can lead to unintended consequences since paper now has two separately assigned mouseup functions. In your case, I'd just stick with addEventListener.
I wrote React component which listens to few types of js events (click, scroll, keyup). For the first time it seems work's well, but I noticed that on my IPad click events are ignored. I attached my Ipad to Safari remote debugger but haven't found any errors in console.
I think the problem is in the following line.
const windowClickStream = Rx.Observable.fromEvent(window, 'click');
it works in Chrome and Desktop Safary but doesn't work on my Ipad.
My question is:
how to get portable Rx stream of all click events on the web page?
I had a similar problem few months ago and solved this by changing the event listener. The "click" event is at first for desktop applications with a real mouse or touchpad. It takes 300ms until the event is triggered because the browser waits for an additional click to trigger a "dblclick" event. The webkit browser fire an "touchstart" event immediately after you touch the screen.
I'm currently working on an app that has some legacy Flash pages. We recently added a dropdown in the header that opens into a scrollable div. The header and dropdown are HTML.
Here's a wireframe to illustrate the set-up.
https://wireframe.cc/27ahkk
We ran into an issue where using the scroll wheel while hovering in the dropdown did not behave as desired.
Dropdown does not scroll
Flash content scrolls instead
I expected this was because, as part of Flash's processing of the wheel/mousewheel events, it was preventing bubbling and preventing the default action. I did some initial tests in Chrome and found that any event listeners I attached to the bubble phase were in fact not called.
My solution was to attach a wheel/mousewheel event listener to the window on the capture phase. In that handler, if the mouse is hovering over our dropdown, I call event.stopPropagation() to prevent the event from ever reaching Flash (thus allowing the default action to occur). Roughly:
window.addEventListener("wheel", function (event) {
if ($('.dropdown-selector:hover').length != 0) {
event.stopPropagation();
}
}, true);
This event is removed when the dropdown closes.
This worked fine in Chrome, and it works in IE as long as you fall back to the deprecated "mousewheel" event instead of using the more modern "wheel" event. Firefox, however, is a different story.
While Firefox supports the "wheel" event, it seems that the way in which events are sent to Flash from the browser is entirely different.
If you are hovering over the dropdown and scroll with the mouse wheel:
The handler will fire
The if condition properly detects the hover
event.stopPropagation() is called
However, Flash content still scrolls
Dropdown div does not scroll
Even stranger, if you are not hovering over the dropdown and you scroll with the mouse wheel:
The handler never fires
Flash content scrolls
This is different than the observed behavior in Chrome and IE, where scrolling while hovering over Flash will still fire the handler, but since the mouse is not over the dropdown, event.stopPropagation() is never called and thus it captures down to Flash where the event will be handled.
This is confusing to me because I attached the listener to the window in capture phase, so I should be receiving the event before anything else on the page. But in Firefox, it appears that either Flash gets the events even before window, or Flash receives a different event altogether (Flash appears to receive these events even if the JavaScript is stopped on a breakpoint in the debugger).
Does anyone have experience with Flash and Firefox and have a better understanding of how the browser sends events to embedded Flash content? Why does my strategy work in all the other browsers but fall short in Firefox? Any possible workarounds before we try to delve into the Flash code itself to work on a solution?
So I found a fix for this issue, although not entirely sure why it works. Even though Firefox supports both the "wheel" and "mousewheel" events, registering our listener to these events did not produce desired behavior. However, listening to the "DOMMouseScroll" event worked beautifully.
Not sure if this is due to some browser-specific logic and/or how our legacy Flash code handles scrolling, but it works so I'm satisifed. :)
I am curious about this one. Does creating a div imitating a button (with 'click' event binded to it) is user-friendly? I mean, does all mobile browsers accurately treat it and always fire event when div is clicked?
Does replacing such constructions with normal buttons increases responsivness on mobile devices?
Google describes this pretty well i think here.
So as described there, handling the click event adds a 300ms delay because it is waiting to see if it is a double-tap.
The technique involves a bit of JavaScript that allows the button to
respond to touchend events rather than click events. Touchend events
are fired with no delay so this is significantly faster than click
events, however there are a few problems to consider:
If the user tapped somewhere else on the screen and then invokes a
touchend on the button then we should not fire a click.
If the user touches down on the button and then drags the screen a bit and then
invokes a touchend on the button then we should not fire a click.
We want to highlight the button when the user touches down to give it a
pressed state.
We can solve the first two problems by monitoring touchstart and touchmove events as well.
We should only consider a touchend on the button if there was previously a touchstart on the button. Also if there exists a touchmove anywhere that goes past a
certain threshold from the touchstart then we should not handle the
touchend as a click.
We can solve the third problem by adding an onclick handler to the
button as well. Doing so will allow the browser to properly treat it
as a button, and our touchend handler will ensure that the button is
still fast. Also, the presence of an onclick handler serves as a good
fallback for browsers that don’t support touch events.
Another advice from experience would be to avoid anchors for buttons.
They recommend using Touchend instead of click.