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.
Related
I have a responsive website WebsiteA, and I'm opening another responsive WebsiteB using an iframe.
I needed to make the iframe responsive as well (to take the full width and height of it's container div), so I did that with absolute positioning.
This is working fine in the browser, I can resize the screen and the iframe is behaving in a responsive manner, and I'm still able to interact with WebsiteB inside the iframe normally, like clicking the links, buttons ...etc
But once I use a device emulator (in chrome dev tools), or use an actual touch device (mobile, tablet), when I try to touch any of the controls (links, buttons ...etc) in the iframe (WebsiteB), then it seems that the touch events are being received at the wrong location, Therefore event handlers are not working.
Has anybody encountered this issue?
I'm building a full screen slider. The last slide is supposed to have a horizontal scrolling area. I'm using css translations (for a smoother animation) to bring the div inside of the viewport.
For some reason, the scrollbar won't work unless you resize the window.
My guess is that when the scrollable div is created outside of the viewport, it is not rendered by Chrome (for performance reasons?).
Then I guess when you resize, the whole thing gets calculated and redrawn and then it is taken into account.
Here is a JSFiddle that illustrates my problem.
http://fiddle.jshell.net/f3thbjqc/6/show/
Here's a video that illustrates my problem (when I wiggle the mouse is when I try to scroll right, unsuccessfully. Then I resize, and it starts working).
My setup: Mac os High Sierra. Both Chrome 69.0.3497.100, and Safari 11.0.1 (13604.3.5) behave the same, firefox doesn't have the bug somehow
Had a similar problem with the materiallize framework when i was usings tabs and a slider inside. The problem was the slider was not working and after I resized the window it was working perfectly.
Try to fire this event manually when the slider is in view
window.dispatchEvent(new Event('resize'));
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
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.
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.