I am working on the beginnings of a mobile website intended for the iPad 2, which can be seen here.
When you swipe the red background, it shows the blue background to the right, but resets because no content was chosen. To choose content, one must either: (a) hold the left mouse button over one of the sidebar icons (A through E), then drag to the left more than 72 pixels (any less and it will reset, as it may have been an accidental swipe); or (b) simply click on (or tap) a sidebar icon.
The problem is, while (b) works just fine, (a) doesn't. In Chrome after a short distance (perhaps equal to the minimum swipe distance setting), it shows the "not allowed" cursor and the "mouseup" event is not registered after releasing the left mouse button. You can test out the link above in Chrome for yourself.
Can anybody determine why this is happening? The relevant JavaScript can be seen here.
When you drag a link (<a href="...">) on Chrome, it takes a while (i.e. the mouse must have moved a certain distance) until the drag starts off. When the drag has started, you can drag the URL to somewhere else (e.g. to the tab strip to open it in a new tab), but it prevents you from using drag functionality yourself through scripting.
The solution is to add draggable="false" so that Chrome doesn't exhibit this native drag behaviour:
...
Related
It's a bit tricky to explain, so maybe the easiest way to understand the problem is to go to the site web and compare the behavior between Firefox (working perfectly as expected) and chrome (scrollIntoView is not working).
Basically, I have a left column menu but I didn't wanted to put a position: fixed so it's a relative one with a float. So the scroll for the main content is with overflow-y on .
Now, I have a "welcome" image which takes all the screen height of the visitor. The behavior I created is when the visitor scroll down, it goes straight to the end of the image. And when the visitor is just below the image and scroll a bit up, it goes directly to the top of the image. Apart from that, the scroll in the text works ordinary.
Everything is working fine with Firefox but Chrome is not scrolling into view as expected. See the scroll.js file in the website linked above, console.log shows that chrome is catching the wheel event and entering scrollIntoView but doesn't scroll.
Is that a bug in chrome that I should report?
thanks
You have to look at the WheelEvent.deltaMode value to know how the brwoser is reporting the wheel event:
WheelEvent.deltaMode
Read only
Returns an unsigned long representing the unit of the delta values scroll amount. Permitted values are:
Constant Value Description
DOM_DELTA_PIXEL 0x00 The delta values are specified in pixels.
DOM_DELTA_LINE 0x01 The delta values are specified in lines.
DOM_DELTA_PAGE 0x02 The delta values are specified in pages.
A good library to standardize the wheel events across browsers is https://github.com/basilfx/normalize-wheel
I've run into a glitch in chrome on iOS where "scrolling" the screen down after an input focus causes the keyboard to obscure the bottom part of the page and a user cannot scroll down to see the elements below (this is where I have a textarea). This happens only in the iOS Chrome browser, not safari.
I'm going to walk through the steps to try and make this as clear as possible.
A user focuses the textarea input. The behavior is as expected here: the keyboard pushes the screen up.
If the user doesn't scroll at all and taps out of the input then this behavior will continue the next time they focus in the textarea (keyboard pushes the entire screen up).
If the users drags the screen down to scroll up while the textarea is focused (no matter how little they "scroll") the screen has a snap-like effect and the keyboard covers the bottom of the content. This keyboard behavior is preserved...
the keyboard continues to cover the content this way each time the user taps in and out of the textarea.
The only way I have found to reset this effect is to pull the screen up when the textarea is not focused. This causes a little flicker effect and when the user clicks into the textarea the keyboard goes back to
I have "scrolling" in quotes because there is no actual scroll happening on the page as the height, body, and form are all 100% the height of the browser. The virtual keyboard really just pushes the viewport off the screen in the first scenario.
I made a video of the issue here: https://youtu.be/yD0tjMfy5I8
I can't find any information about why this is happening and I've not had any luck trying to style the form differently because (from what I can tell) there is no way to find the height of the visible area when the keyboard is opened (window.innerHeight doesn't work)
Has anyone found a way around this glitch?
A web page I am developing has mouse over events (both css and javascript) for a top navigation bar. It works fine when the browser window is floating, but when maximized (full screen) the hover classes have no effect anymore. It begins to act like a tablet display, I must point and click for my hover actions to take effect. I achieve the events when I click, but mouse hover changes my cursor to a text select cursor.
This does not happen on a windows computer
As a matter of fact, this behaviour is good if it is meant to support tablets but I'd appreciate if anybody could let me know if this is a bug or intended?
This is a 3+ year old unfixed bug in Chromium.
http://crbug.com/170058
I'm making a small full-screen canvas game to be played on mobile. It involves swiping around the screen with your finger. I have the canvas listening for touch events (down, move, up).
Unfortunately, the browser tries to interpret swipes left and right as browser tab navigation, and swipes up and down as hide/show URL. I don't care if the URL is hidden or not, I just want everything to stay still.
As a result of everything moving, it intermittently stops recognizing inputs to the canvas.
The way I have it set up is a canvas that takes the size of the screen, set its position to fixed at 0,0. This is to prevent scrolling (which works, except for the hide/show url thing).
If you want to see an example, here's where I'm hosting it:
http://phildogames.com/scratch/sust/index.html?game=window (you won't be able to interact on desktop because it's listening for touch events, but if you view it on mobile you should be able to open and close the windows).
tl;dr: I want to tell the browser to simply pass swipes (well, all touch events) to the dom and stop interpreting them as intents to scroll, switch tabs, hide/show URL, etc..
Thanks!
I was able to solve your problem by simply preventing touches on the body.
var myBody = document.getElementById('dabody');
myBody.addEventListener('touchstart', function(e){
e.preventDefault()
});
You can throw that in console to test. Tested on iOS Safari and Android Chrome.
I wonder if there's any way to detect if the user made a two-finger tap on the MacBook trackpad with JavaScript or jQuery. In one of the projects I'm detecting right mouse click with JavaScript and using it for some actions. It actually doesn't work when you make a double finger tap on a trackpad. While in action that works as a right click, but JavaScript can't detect it like so.
Any clues?
You can use the mouse events button property - MDN reference
A value of 1 would be the indicator of a left click
A value of 2 would be the indicator of a right click.
Demo jsFiddle