iOS web app: input ignores touch events - ios

I'm trying to disable page scrolling using
$('body').on('touchmove',function(e){e.preventDefault()});
In Safari everything works as expected but in fullscreen mode only input and textarea don't prevent scrolling and ignore any touch event. I think it started in iOS8.
Here's example:
<!doctype html>
<meta name="apple-mobile-web-app-capable" content="yes">
<meta name=viewport content='width=device-width'>
<body ontouchmove="event.preventDefault()">
<div>
<p>Lorem ipsum dolor sit amet</p>
<p>Lorem ipsum dolor sit amet</p>
<p>Lorem ipsum dolor sit amet</p>
</div>
<input value='Input'><br>
<textarea>Textarea</textarea><br>
<div contentEditable=true>Editable div</div><br>
<button onclick='location.reload()'>Reload</button>
Am I missing something?
Is it possible to prevent scrolling on touching <input>?

Seems that touchevents in a standalone web-apps launched from homescreeen are back with iOS 8.1.3 :-)

Related

Accessibility: Talkback will read contents of dialog automatically. But NVDA and VoiceOver will not read

I have implemented Bootstrap(3.3.7) modal for the popup. Talkback will read contents of the modal automatically when it loaded starting from close icon.
But, in VoiceOver it will not. In VoiceOver when modal is opened the focus will move to first interactive elements like button(close button).
<div class="modal fade in" id="alertID" tabindex="0" role="dialog" aria-hidden="false">
<div class="modal-dialog" id="leaving-modal-content" role="document">
<div class="modal-content leaving-site-content">
<button aria-label="Close Dialog – button" class="close-icon" data-dismiss="modal"><i class="fa fa-times"></i></button>
<h2 class="headline-text11"><span class="large-modal-text1">Example Title</span>
</h2>
<p class="body-copy">Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has survived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged. It was popularised in the 1960s with the release of Letraset sheets containing Lorem Ipsum passages, and more recently with desktop publishing software like Aldus PageMaker including versions of Lorem Ipsum.</p>
<ul class="list-inline">
<li>Continue</li>
<li>Cancel</li>
</ul>
</div>
</div>
</div>
If anyone can come up with the solution. It would be a great help.
#slugolicious I have got solution from you couple of times.
Please, help me out.
Thanks in advance :)
Not sure if this affects anything, but I don't normally put a tabindex="0" on the dialog itself. I use tabindex="-1" so that I can send the focus there programmatically but the user cannot tab to the dialog border itself.
Also, VoiceOver sometimes has trouble with dialogs that are display:none > display:block rather than visibility:hidden > visibility:visible. That is, if you hide your dialog initially with display:none, and then unhide it by setting display:block, sometimes VoiceOver won't move the focus to the first element in the dialog. See the "Additional Gotchas to watch out for" in Scott O'Hara's blog. If you initially hide with visibility:hidden and then unhide by setting visibility:visible, it works better. But that's only an issue on VoiceOver and only has to do with moving the VoiceOver focus.
However, I think the main problem is that your dialog doesn't have a label or description. You have a heading in the dialog but the dialog itself should point to that heading. Just add an ID to the <h2> and then refer to that ID in the aria-labelledby attribute of the dialog.
If you have other text in your dialog that describes the dialog's purpose, you could put an ID on that description and then refer to it by adding an aria-describedby to the dialog too. Very similar to the aria-labelledby. In the example below, I'll use the "lorem ipsum" paragraph as the description.
Something like:
<div class="modal fade in" id="alertID" tabindex="-1" role="dialog" aria-hidden="false" aria-labelledby="newID1" aria-describedby="newID2">
<div class="modal-dialog" id="leaving-modal-content" role="document">
<div class="modal-content leaving-site-content">
<button aria-label="Close Dialog – button" class="close-icon" data-dismiss="modal">
<i class="fa fa-times"></i>
</button>
<h2 id="newID1" class="headline-text11">
<span class="large-modal-text1">Example Title</span>
</h2>
<p id="newID2" class="body-copy">Lorem Ipsum...</p>
...

md-select causes white screen if clicked after IOS focuses on an input feild

On IOS, if a user clicks inside a text input field (IOS focuses it), then selects done on the keyboard, then clicks on an md-select, the view white screens until the user clicks on the screen. It seems to be in part due to the IOS focus on the initial input field. If you zoom out of that focus before clicking the md-select, the white screen issue does not occur.
<md-input-container>
<label for="fname" class="required">First Name</label>
<!-- user clicks on this, IOS focuses on it -->
<input type="text" id="fname" required="required" data-ng-model="occupant.fname">
</md-input-container>
<md-input-container>
<!-- user clicks on this after IOS focus on above element, white-screen occurs -->
<!-- white-screen does not occur if you zoom out of the focus before clicking on this -->
<md-select data-ng-model="bed.occupants" placeholder="occupants">
<md-option data-ng-value="occupant" data-ng-repeat="occupant in occupants">
{{ occupant.fname }}
</md-option>
</md-select>
</md-input-container>
This issue is fixed by adding this meta info to your main html file:
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1.0, user-scalable=no">

jQuery Mobile data-icon=bars displaying as plus icon when using Doctype

Looking for a workaround to get around this or if there is a better way to resolve the issue I am open to adjusting the code..
Here is the situation:
If I do not use a doctype then the bars icon is appearing just fine within a controlgroup, however as soon as I add the doctype then it seems to flip to the plus icon instead.
The only change is adding the doctype to the top of the file and the icon flips from bars to plus.
Doesn't matter if it is jQuery Mobile 1.3.1 or 1.3.2, having the same results
Has anyone encountered this or found a way around it? I really want the bars icon to be displayed and am trying to avoid not using the doctype declaration so the code can validate properly.
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<style type="text/css">
#import url('include/jquery.mobile-1.3.2.min.css');
</style>
<meta name="apple-mobile-web-app-capable" content="yes">
<meta name="apple-mobile-web-app-status-bar-style" content="black">
<meta id="viewport" name="viewport" content="initial-scale=1.0; maximum-scale=1.0; user-scalable=0;" />
<meta name="apple-touch-fullscreen" content="NO" />
<script src="include/jquery-1.9.1.min.js"></script>
<script src="include/jquery.mobile-1.3.2.min.js"></script>
</head>
<body>
<div data-role="page" id="mobile">
<div data-role="content">
<div data-role="controlgroup" data-type="horizontal" class="ui-body">
Test
</div>
</div>
</div>
</body>
</html>
EDIT: Same issue occurs with the GRID icon
This is just a typo. Replace
data-icon="Bars"
with
data-icon="bars"
And your'e good to go. You have to follow the exact case when it comes to images. The full set can be found here : http://api.jquerymobile.com/icons/
Here's a demo : http://jsfiddle.net/hungerpain/cpRh2/1/

Jquery UI 1.10.x Dialog drag issue on large body height

In short: When You have document height > window height, scroll down and open dialog - You can not drag it in Firefox. Bug occured only in jQuery UI 1.10.x
How to reproduce:
jsfiddle:
http://jsfiddle.net/mefa/zrNNZ/15/
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="content-type">
<title>Jquery UI FF dialog bug - jsFiddle demo by mefa</title>
<script src="//code.jquery.com/jquery-1.9.1.js" type="text/javascript"></script>
<link href="/css/result-light.css" type="text/css" rel="stylesheet">
<script src="http://code.jquery.com/ui/1.10.3/jquery-ui.js" type="text/javascript"></script>
<link href="http://code.jquery.com/ui/1.10.3/themes/smoothness/jquery-ui.css" type="text/css" rel="stylesheet">
<style type="text/css">
html {
font-size:12px;
}
body {
height: 2000px;
}
</style>
<script type="text/javascript">
$(window).load(function(){
$(function() {
$( "#dialog-modal" ).dialog({
height: 150,
modal: true
});
});
});
</script>
</head>
<body>
<div title="Basic modal dialog" id="dialog-modal">
<p>Drag this dialog to bottom of document in Firefox</p>
<p>Bug only in jquery ui 1.10.x</p>
</div>
<p>Sed vel diam id libero rutrum convallis. Donec aliquet leo vel magna. Phasellus rhoncus faucibus ante. Etiam bibendum, enim faucibus aliquet rhoncus, arcu felis ultricies neque, sit amet auctor elit eros a lectus.</p>
</body>
</html>
Video: http://www.youtube.com/watch?v=_J8aepYHg4U
So, assume U have a Jquery UI Dialog, and tag <body> has vertical scroll (for example You have much content, big table for example). Assume Your window height is 800 px and document height is 2000 px; So U need to scroll down, to get all contents.
Then You scroll down, over the window height, for example to 1000px, open dialog. After that You can't correctly drag it into any other position, because it's jumps like a mad.
Ive recorded a demonstration, based on the original jquery ui examples, so no one can say I missed or corrupted something.
Only one thing Ive changed is body css attr "height", and set it to 2000px to simulate large document.
I appreciate any advice/fix.
this is a bug in jquery-ui version 1.10.3
You can fix this by including previous version :
<script src="http://code.jquery.com/ui/1.10.2/jquery-ui.js" type="text/javascript"></script>
Suddenly, Ive found a solution.
To fix this bug, You need only to add following CSS rule
.ui-dialog {
position: fixed;
}
But this also has side effects.
If part of dialog is out of window scope, then no vertical/horizontal scrollbars appeared, and You can't reach hidden part of dialog in any way.
Need to wait properly fix from Jquery UI team.
The real fix is to replace _convertPositionTo() and _generatePosition() in jquery.ui.draggable.js from those in the latest master (1.10.3 is official current release, so the fix should come out in 1.11) for those who run into it now and can't use those css hacks.
i have tried some thing for you
it is not the best but you can try it.. i hope
re place your code as
$(function() {
$( "#dialog-modal" ).dialog({
height: 150,
modal: true,
dragStop: function( event, ui ) {
$( "#dialog-modal" ).dialog({ position: 'center',draggable: true });
}
});
});
when you up the mouse click it will stick to center of your screen... as example i have keep it at center but you can keep it any where... just go through documentation.

jQuery Accordion + Anchor Tag 'stuck as block' bug?

Sample page:
http://jsbin.com/ohuze/2
This is a simple jQuery UI Accordion. Each accordion panel has an UL (an OL works the same) with this markup:
<ol>
<li>Lorep ipsum dolor lorem ipsum dolor lorem ipsum dolor?</li>
<li>Lorep ipsum dolor lorem ipsum dolor lorem ipsum dolor?</li>
</ol>
In IE6, you'll see that the <a> tag appears to be getting rendered as a block element, so the question mark ends up being pushed outside and not at the end of the line of text. In addition, the bullet and/or list item number is now bottom-aligned with the text rather than top-aligned.
I've narrowed it down to the javascript that executes to make the accordion. It's not an issue with jQuery's CSS as disabling that, alone, doesn't resolve the issue.
Anyone know what might be going on in IE6 to cause this rendering issue?
UPDATE: Apparently, this is also an IE7 issue.
UPDATE 2: After some more playing, I've narrowed things down a bit more:
the bug has nothing to do with lists. The issue is any anchor tag within a jQuery Accordion will appear as display: block (even though it appears that the CSS still indicates display: inline)
the bug has nothing to do with the actual CSS that jQuery UI uses to create the accordion. I created a test page that uses the fully rendered jQuery Accordion post-processed source code and the accompanying CSS. In that situation, the anchor tags remain inline.
In conclusion: It appears that the process of rendering the accordion via javascript is messing up the display of the anchor tags. It may be a show/hide issue?
Solution:
Turns out (no surprise) that it's a has-layout issue with IE6. When jQuery UI kicks in to build the Accordion, somehow the anchor tags lose layout (or are they given has-layout?). The solution is to add a call back function that re-sets it to (I think) NOT have has-layout:
$('.myDiv').accordion({
collapsible: true,
autoHeight: false,
active: false,
change: function(){$(this).find('a').css('zoom','0')}
});

Resources