iPhone vs Javascript event suppression - javascript

I've got a simple click handler that does something on the screen instead of visiting that link. Here's the code (I'm cutting out the nonsense but the important stuff is accurate):
Link Text
<script type="text/javascript" src="./path/to/jquery.js"></script>
<script type="text/javascript">
$('#others').on('click', function(ev){
ev.preventDefault();
ev.stopPropagation();
// Doing stuff (some simple DOM manipulation)
return false;
});
</script>
This works fine on proper browsers. It works fine on Android (both older webkit and newer Chrome builds) and it works fine on iOS on the iPad 2... But one of my users is using an iPhone 4 and that's where all the fun starts.
When they click the link, the link loads. Despite three separate triggers not to, the event is still firing. Other javascript is working on the page and as I say, this is working everywhere else. Actually to confuse things a little more, the event is suppressed very, very occasionally. Less than 1% of the time.
So is this a known issue with iPhones? Is there a better way of doing all this?
The javascript is loaded at the end of the body (still inside it, but after all the DOM elements it mentions). jQuery version is 1.10.1

try using href="javascript:void();"
Link Text
$('#others').on('click', function(ev){
//ev.preventDefault();
//ev.stopPropagation();
// Doing stuff (some simple DOM manipulation)
return false;
});

Related

JQuery Mobile 1.4.5 does not seem to invoke javascript on ipad

Using JQuery mobile 1.4.5 (https://jquerymobile.com/)
Ironically, everything works on desktop browsers, but I cannot seem to get anything to work when testing on an iPad ...
My stripped down page (HTML) contains the following:
<div data-role="content">
<script src="test.js"></script>
<script>
$( document ).on( 'pagecreate', function( event ) { do_something(); });
</script>
</div>
The file "test.js", contains the following code:
function do_something() {
alert('here in do_something()');
}
When testing on an iPad, all I get is a grey circle with a "spinning comet" rotating around in the circle and the page never even renders (Yes, I tried rebooting the iPad, clearing browser history/data, etc).
On all other browsers, I get the alert.
Ultimately, I am trying to load google maps into the page along with the javascript I need to manipulate various DOM elements as well as manipulate the map -- which I CAN do and is working on all other browsers -- just can't seem to get anything to work when testing on an iPad (I do not know how to view source or console messages via iPad Safari, which makes debugging a nightmare).
ANY suggestions would be helpful.
Thanks in advance.
First of all, you missed some important information like, were "all other browsers" running on your desktop machine or are we talking about other mobile devices? This is extremely important.
As you can see spinner that would mean jQuery Mobile and jQuery are loaded.
If they were successfully running on your desktop computer then you may check these:
Make sure none of your content is running on or from localhost. This will work just fine on desktop computers, but if you try to test it on any other device it will fail.
Make sure you are not using an absolute path in your jQM application, this will also fail on any remote device. I presume something similar may be the case as jQM is not able to show the first page
You will need to use a remote debugging feature. As you are using an iPad I again presume you own a Mac. Follow this tutorial: https://appletoolbox.com/2014/05/use-web-inspector-debug-mobile-safari/ as it is the only fool-proof method where you will find what was wrong. Unfortunately, if you are using Windows machine then you would need to use Chrome and Android device.
There's also a chance, some of your *.js content is loading from localhost or other sources not available to your iPad. This also may be the case as you stated above alert is not triggering on iPad. Which would mean that some major JavaScript has occurred thus blocking the load of other JavaScript content.
And there's one other foolproof method you can use that always helped me in this case. Trim your code to the bare minimum, even if that means you need to remove most of your HTML content and JavaScript. Test it, if it works, start including removed content. First include remote JavaScript content, CSS and similar. Then if it still works, start including actual HTML and code. Sooner or later you will stumble on the problematic code, missing content, or content that was not loaded into your iPad.
Thanks to all who provided some insight...
Turned out it was an external javascript file that contained a try/catch block as:
try {
// code
}
catch {
// code
}
When changed to:
try {
// code
}
catch(err) {
// code
}
... after the change was made, all tests passed !!

Safari refresh prevents jQuery execution

I'm working on a Drupal 7 site, the mobile version of the site which uses Bootsrap as theme.
There is a custom block (created w/ drupal) using jQuery to move some elements on a page, changing some classes and IDs. This block works just fine.
My problem is in a custom module which renders a block. I have some jQuery code in the module's template that is not running on refresh in Safari, but it runs if I go on the address bar and hit "Go" on the keyboard.
edit: IE and Chrome seem to also have a problem, but the jQuery code runs sometimes, doesn't matter if is a refresh, clear cache or whatever.
Nothing special in browser's console.
My jQuery code is supposed to move some elements in the page, on jQuery(document).ready, but is not even working for a simple alert.
p.s.: the jQuery in my custom module's template doesn't have anything to do with the code or the HTML elements affected by the custom block, but I thought maybe it would be good to mention it.
I hope you can understand the issue :)
Thanks.
I was using jQuery(document).ready to execute my code. I changed to jQuery(window).load and now it works fine. The code executes on first page load and on every refresh.
After like two weeks and almost killing myself, this is only thing that worked for ios safari.
$(window).on('load', function () {
setTimeout(() => {
DoLoad();
}, 180);
});
I had a similar problem and tried probably a dozen or more ways to address an issue with Safari. It looks like Safari triggers $(window).on('load',...) jQuery call before DOM completely builds. Or perhaps there is some kind of timing/racing condition. In my case, it was causing an issue, but only after page reloads, only with Safari, and only with a certain cloud provider. Chrome was fine, on prem hosting was fine. The only way which worked somewhat reliably was to introduce an artificial delay via setTimeout() function.
$(window).on('load', function () {
setTimeout(() => {
$.getScript('{{url}}').done(function(){
$("#element").js_function({
arguments
});
});
}, 360);
});

Dynamically loading jQuery mobile causes IE to minimize

Okay, this is by far the weirdest bug I have ever encountered. It's pretty straightforward though. If I load jQuery and then jQuery mobile dynamically in any version of Internet Explorer, the actual IE window minimizes. This happens in all versions of IE through IETester, however, if I run the full version in IE9, it kicks compatibility mode and for some reason doesn't minimize.
I've tried various ways of loading the scripts (commented in the example code), all resulting in the same behaviour.
Why is this happening? Is there a way around it?
http://jsfiddle.net/Xeon06/RCsuH/
This is a known issue in jQuery mobile. The offending line is jquery.mobile.navigation.js:913.
// Kill the keyboard.
// XXX_jblas: We need to stop crawling the entire document to kill focus. Instead,
// we should be tracking focus with a live() handler so we already have
// the element in hand at this point.
// Wrap this in a try/catch block since IE9 throw "Unspecified error" if document.activeElement
// is undefined when we are in an IFrame.
try {
$( document.activeElement || "" ).add( "input:focus, textarea:focus, select:focus" ).blur();
} catch(e) {}
There's the call to blur() that's sending IE windows to the back of the stack.
As a workaround, you can avoid this by placing the script tags physically in the <head> of the HTML.
<!DOCTYPE HTML>
<html>
<head>
<link rel="stylesheet" href="http://code.jquery.com/mobile/latest/jquery.mobile.css" />
<script src="http://code.jquery.com/jquery-1.6.2.js"></script>
<script src="http://code.jquery.com/mobile/latest/jquery.mobile.js"></script>
...
Placing the script tags elsewhere in the document or inserting them via script triggers the bug.
This Fiddle demostrates the workaround in action. Note that this only works in a top-level document. If the document is in an <iframe>, the bug will still appear. Thus, if you open the JSFiddle editor in IE 7/8, it will still get sent to the back; but if you open just the rendered HTML, it will not.
My attempt at "fixing" it: http://jsfiddle.net/RCsuH/6/
#josh3736 was almost exactly right, somewhere in the code it is firing off a document.body.blur() which causes the minimization of the window.
My fix simply replaces that function with a no-op function. I was unable to get the script tags to fire an onload when they finished loading, so replacing the function (if necessary) is left up to you.
However all of this seems to be a bug in the jQuery Mobile library, and thus you should probably file a bug report with them. However, I'm not sure it will bother them too much that there is a bug on IE for a framework that is intended for mobile phones/tablets.
Note: This is horrible, horrible code that replaces native functions. If it is possible, don't use this.

Using Javascript to resize browser window in IE8. Explanation mostly

I have seen many examples on using javascript to resize a browser window, but for me they all fail to perform that function in IE. I include my code to see if anything is wrong with it that I just don't see. The code works great in FF but that is not used at my location.
I am no javaScript expert, but I am no slouch either. If I were new to javaScript I would be hating it. I'm sure it has something to do with IE but I cannot explain it.
Any help would be great.
CODE:
//window.sizeToContent();
window.resizeTo(700, 700);
I read in the docs that sizeToContent will not work in IE but resize should. It is an incredibly simple statement.
This works for me in Internet explorer 8
<html>
<head>
</head>
<body>
<h1>Resized</h1>
<script>
window.resizeTo(400,400);
</script>
</body>
I did some testing in IE9 beta (that's the only version of IE that I have on this machine), and it seems that window.resizeTo does not work on the initial page load. It does work if you refresh the page. Also, it does work if you delay its execution:
setTimeout(function() {
window.resizeTo(200, 200);
}, 2000);
(at least in IE9 beta)
The "working" example with IE is working only because there are no more tabs on the window.
If the windows has other tabs loaded, then it DOES NOT work. It's a security measure of IE8 and higher.
If you need to resize your window, you will need to open a new window. And for that, you will need to make the user click a button with the window.open onclick event, otherwise any popup blocker will block it.
You won't be able to resize the window reliably with JavaScript. It's not possible in IE 7 with tabbed browsing enabled. It's also potentially annoying for the user.
This seems to be IE only.
If your window is a "dialog" like:
window.showModalDialog(url,...)
I found this hacky way to make it the right size:
<script type="text/javascript">
//window.resizeTo(1000, 790); //Will not work if its a dialog
window.dialogWidth = '1000px';
window.dialogHeight = '790px';
</script>

JQuery Problem: Script (Sometimes) Fails On (Some Versions Of) IE7

I'm using an image cross-fading method via jQuery on a website. For confidentiality reasons, I can't post the site's entire code, but here's the Javascript for the cross-fader (based on this reference):
<script type="text/javascript">
$(function () {
if ($.browser.msie && $.browser.version < 7) return;
$('#nav li')
.removeClass('highlight').find('a').append('<span class="hover" />').each(function () {
var $span = $('> span.hover', this).css('opacity', 0);
$(this).hover(function () {
$span.stop().fadeTo(250, 1);
}, function () {
$span.stop().fadeTo(250, 0);
});
});
});
</script>
It works swimmingly on all browsers -- including the IE7 install on my test PC. However, on other PCs with IE7, the effect sometimes fails. The images will load, but hovering over them produces no effect. This means the JS isn't outright failing -- in that case, the rollovers would still work, just with no fading. Instead, it seems that IE7 is removing the "highlight" class, but then stopping.
The truly bizarre part? The failure is 100% random. If I refresh the window, sometimes the effect will work fine. How can this be?
UPDATE: I've determined that the problem lies somewhere with the AJAX scripting that's powering the website. Removing all AJAX and replacing it with static content eliminates the error. My theory is that when the page loads, sometimes the AJAX content is completed before the image load. This makes IE7 freak out and give up on the crossfade effect. If I'm correct that this is the problem, the question is: how can I fix it?
UPDATE 2: Going further down the rabbit hole, using Fiddler, I notice one consistent thing for each successful load of the effect in IE7: the loading of the main image that I'm using for the hover is aborted, then loaded again. This does not happen when the effect is unsuccessful. To put it another way, forcing the browser to preload the images using a simple jQuery preloader function breaks the cross effect in IE7 every single time, instead of its current sporadically-working state.
This is just too bizarre for me to even comprehend, but any ideas are certainly welcome.
Is your CSS included before you call the ready function? From the docs:
Note: Please make sure that all stylesheets are included before your scripts (especially those that call the ready function). Doing so will make sure that all element properties are correctly defined before jQuery code begins executing. Failure to do this will cause sporadic problems, especially on WebKit-based browsers such as Safari.
I understand IE is not WebKit based, but it's worth checking.

Categories