Mac Chrome hover events behave differently when window is maximised - javascript

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

Related

android webview image in overflow div not draggable if it has links on it

I have an android app that uses webview to render large images in a div. The div has fixed width height to match the screen leaving some area on top for controls. The image has an image-map on it and areas created with links.
Now the issue is that when I drag the image from non-mapped areas, it works fine, but when I drag from mapped area, it does not work and I think stucks in the touch event (because I also see the orange focus border on the image map area that opens links).
This happens only when the page is run from within app+webview, but if I load the page in browser on same mobile, it works fine.
Also this does not happen in my Android 5.1 Vega IRON, but it happens in older phones like Android 4.4 Droid, and same version Huawei.
Is this some known issue?
This might have something to do with touch events in application, as it works in browser but not in application.
I found out that in some conditions, the image-map does not let the mouse button events go past, therefore it does not perform even the default dragging and click behavior.
I had to remove image-map and build my own absolute positioned and display:block <a> tags for each area, and then it worked.
Hope this helps someone.

Deadzone in iPhone 6 Plus, Safari, iOS8. Bottom area loses interactivity when tabs are visible

I'm making a webapp and want to use all the screen and avoid scrolling if possible. There will be buttons that need to be clicked in many areas of the page.
The area at the bottom of mobile safari is not clickable when the tab bar is open and I rotate to portrait and back to landscape.
I have set the body height to the same as window.innerHeight instead of 100% so that I don't have to scroll to get to buttons at the bottom.
bodyEl.style.height = window.innerHeight + 'px';
It may be the case that this area is not usable for interactive content.
Here is a demo with code:
http://plnkr.co/edit/327sUQ?p=preview
You should be able to open a preview of it on iPhone 6 Plus by clicking on the fullscreen button 'Launch the preview in a separate window'.
Update:
It definitely looks like it was a bug in iOS8, it's working as expected in iOS8.4, 9.0 & 10.2 from my simulator.
I may have found an answer to your issue, but would love to hear if you can confirm. Setting the content of your page to have the following styles:
overflow-y: scroll (allows you to scroll below the viewport, but only if necessary per the length of the content; the default value is visible)
-webkit-overflow-scrolling: touch (to smooth any scroll behavior)
in addition to your height: 100% (which forces the content to fill the viewport)
appears to force the iOS menu (tabs and address bar on top as well as nav bar on the bottom) in Safari to always appear. That way, button clicks to the top and bottom of the page are no longer "dead zones" and will actually work instead of opening up the Safari menu.
I'm searching for a solution for a similar problem - this is not an answer, but an attempt of explanation.
First of all - currently, I cannot confirm this behavior - seems like it's fixed in iOS 8.4 (12H143). Didn't know exaclty in which version I saw it the last time.
Nethertheless, I try to explain what I've found out (until we decided to not bother anymore).
The not clickable area is not always a dead zone. If you scroll up before you click, chances are high you get it working. Thus I think the (empty) standard navigation bar is there (height and behavior of the elements are similar/the same), even if it's empty (all element moved to the address bar) in landscape mode.
Btw.:
There's another (similar) problem with the iPhone 6 plus (not fixed yet).
If you have a position: fixed element on the top of a webpage, in landscape mode and only if there are two or more tabs open (and the tab bar is visible), you can click through this element (even through buttons) - as if the whole thing isn't there.
I know this question is a bit old, but since the issue still exists I thought I should share my experience...
As of now there is NO fix for the issue, but there is a workaround. The solution jennz0r provided may work for some, but I didn't like the idea of the menu bar always showing. I saw a website that had the issue solved... well it seemed to work at least. I didn't find anything in their css or js.
So what was the fix? Since the "dead zone" is 44px in height they simply made their floating bar 88px height :D Users would instinctively tap on the top/center of the button and it will almost always work at first try!
Another workaround would be to simply make the button/bar float 44px from the bottom.
"If it's stupid, but it works... it ain't stupid..." ;)

Javascript on mobile- tell browser to not hijack gestures

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.

iOS visual flash when altering page length / scrollbar

http://jsbin.com/nesiside/1 (code is available http://jsbin.com/nesiside/1/edit)
If you scroll down in the document and click the "Lock/Unlock" button, an overlay with text will appear. You'll notice that the scrollbar length has been changed to accommodate the overlay height, not the original page height. Click "Unlock" in the overlay, and you return to the original page, in the previous scroll position.
System works great on desktop browsers, and on my Android phone, however, on iOS there is a rendering flash flash when the overlay is triggered or removed. Ultimately, I believe it is the fault of the scrollbar changing.
I've attempted the usual tricks to resolve iOS rendering issues (webkit-backface, transform3d), with no success.
Apparently, showing the content and hiding the overlay (or vise versa) was to much for the iPad 4 to render at once, causing the flash. This is odd because I tested it on an old Kindle and my Android phone and both are handled it fine with their slow processors.
To resolve the issue, I put the the scrollTop() method (used to return the user to the previous position on the underlying page) inside a requestAnimationFrame function. The result isn't perfect (content can be screen scrolling for a fraction of as section), but it is a much better result than an entire page flash.

Android Element Selection Issues

I'm attempting to make my website tablet friendly and I'm facing a strange issue.
I am testing on an Android 4.0 tablet with Chrome 30.
I have a fixed modal popover screen. While this screen is on, we don't want to let the user scroll the background so touch events are prevented. However, in this window we have a scrollable area with overflow:scroll, therefore the touch event is not prevented if the touch start event is detected there. So far so good - Android responsibly scrolls the area as expected.
Problem is, if the user long-presses an element inside the scroll area for about half a second, and only then scrolls - the element where the touch started appears to be selected for a moment. That selection disappears after a bit. But, in case the user scrolls during that bit - the whole page scrolls instead of the scrollable area. It's as if the focus is changed. What's going on?
I tried to set CSS selection rules on the elements inside but it didn't help.
-webkit-touch-callout:none;
-webkit-user-select:none;
-khtml-user-select:none;
-moz-user-select:none;
-ms-user-select:none;
user-select:none;
Every other answer suggests to prevent the touch event which I can't because it's meant to be scrolled. Any ideas what's causing this?
OK, I got it.
Add cursor:default!important to the above CSS rules.
I DID come across such a solution but it failed on first try. In my case, the specificity of elements inside the scrollable area was too strong, rendering cursor:default useless and I didn't realize it. I apply this only to mobile devices by detecting the useragent, therefore I can afford dismissing the previous cursor attribute with !important as it won't affect any desktop clients. Sweet!
Still not sure why this worked. If anyone could supply information on how the cursor attribute affects Chrome on Android I will be grateful.

Categories

Resources