It seems that there's a problem with the way History.js is instantiated, but I'm unsure even about that. On window load, this code (among others) is called:
History.Adapter.bind(window, 'anchorchange', function(event){
and for this code on IE8 I get: Unable to get value of the property 'Adapter': object is null or undefined.
You can see the page at skrobotwp.gandzo.com, everything works fine in newer browsers.
Related
I'm using a custom Modernizr build, v3.3.0. I've created a simple JSFiddle example to illustrate: https://jsfiddle.net/cqkg7x45/6/.
console.log(Modernizr);
will show the Modernizr object, and when I inspect it in the JS console I can see "videoautoplay" is a property with a value of "true".
But, when I do
console.log(Modernizr.videoautoplay)
it returns "undefined".
I was originally seeing this issue in a WordPress theme I'm developing, but was also able to recreate in JSFiddle and a separate stand-alone HTML page. Also, Modernizr is putting the "videoautoplay" class on my HTML tag, even when I know the device does not support that feature (iPhone 5).
Update: This issue appears to be happening in Chrome (v47.0.2526.106), but not Firefox (v43.0.2).
I'm going to answer my own question in case anyone else runs into this problem. I found the solution on this SO post: How do I detect if the HTML5 autoplay attribute is supported?.
Since this is an "async" test you can't access the property using the syntax
Modernizr.videoautoplay
You have to use the .on() function, as shown in the above SO post:
Modernizr.on('videoautoplay', function(result){
if(result) {
alert('video autoplay is supported');
} else {
alert('video autplay is NOT supported');
}
});
I have a phonegap app that uses jqm that works fine in android and ios.
Porting to WP7 i have an issue with the history, specifically history.back() (but also .go(-1) etc). This refers to going back in history where the previous 'page' was in the same physical html file, just a different data-role=page div.
using a jwm site in a regular browser is fine (with separate 'pages' in the same html file). Also, using history.back() when we go from one html file to another in the app is fine. It's the specific combination of WP7.5, jqm and PG.
Has anyone come across a solution for this? it's driving me crazy, and has been as issue since PG 1.4.1 and jwm 1.0.
EDIT 1: It's possible that the phonegap process of initialising the webview on WP7.5 somehow overrides the jqm history overrides, after they've loaded.
EDIT 2: definitely something to do with jqm not being able to modify the history. each time there is a 'page' change, history.length is still 0.
EDIT 3: When i inspect the 'history' object, i found there is no function for replaceState or pushState - i know jqm uses this for history nav, maybe that's the problem.
ok - this isn't perfect, but here's a solution (read: hack) that works for me. It only works for page hash changes, not actual url changes (but you could add a regex check for that). Put this somewhere in the code that runs on ondeviceready:
if (device.platform == 'WinCE') {
window.history.back = function () {
var p = $.mobile.urlHistory.getPrev();
if (p) {
$.mobile.changePage("#" + p.pageUrl, { reverse: true });
$.mobile.urlHistory.stack.splice(-2, 2);
$.mobile.urlHistory.activeIndex -= 2;
}
}
}
I have the Drupal Quicktabs module installed at:
http://ar.sacherokeedev.com/auction-directory
I've also installed the wibiya toolbar, http://www.wibiya.com.
Everything works fine in Firefox and Chrome, but in IE7, with the toolbar enabled, it breaks the ajax tab loading. With the toolbar disabled, IE7 works fine. Wibya has a "Javascript Conflict" mode, and I've tried that as well as changing my DocType, as they suggest.
I've narrowed it down to a couple of things. First, quicktabs behavior is based on the "type" of the tab:
if (tab.tabObj.type != 'view') {
// construct the ajax path to retrieve the content, depending on type
var qtAjaxPath = Drupal.settings.basePath + 'quicktabs/ajax/' + tab.tabObj.type + '/';
switch (tab.tabObj.type) {
case 'node':
qtAjaxPath += tab.tabObj.nid + '/' + tab.tabObj.teaser + '/' + tab.tabObj.hide_title;
break;
case 'block':
qtAjaxPath += tab.qtid + '/' + tab.tabObj.bid + '/' + tab.tabObj.hide_title;
break;
case 'qtabs':
qtAjaxPath += tab.tabObj.qtid;
break;
}
In my case, when using the toolbar in IE, tab.tabObj.type is "undefined". So, I'm thinking that wibiya is hijacking my objects or something.
I also get a runtime error, "Object does not support this property or method" in the following block:
if (!Drupal.quicktabs.scripts[files[i]] && !files[i].match(/^\/misc\/jquery\.js.*$/)) {
Drupal.quicktabs.scripts[files[i]] = files[i];
html += '<script type="text/javascript" src="' + files[i] + '"></script>';
}
Has anyone seen this before, or have any suggestions?
Update: I did console.log(tab.tabObj) and in Firefox and Chrome, I get something that makes sense, an Object with a block id, a type, etc... But in i.e. I get this:
function(fn,thisObj){var scope=thisObj|window;for(vari=0,len=this.length;i<len;++i){fn.call(scope,this[i],i,this);}}
Anyone have any ideas?
UPDATE: I am currently using the Drupal specific wibya module, and the toolbar itself works fine on my site whether one is using IE, Firefox or Chrome. The issue is that the ajax tabs on that page are prevented from functioning by the wibiya toolbar. I'm inclined to agree with #clive that it's a jQuery/javascript conflict, but I'm not sure what I can do about it.
As for running Drupal 6, I inherited the system, and as of now, can't upgrade.
UPDATE: I just tried loading jQuery 1.4 using the instructions at http://drupal.org/node/1058168. That caused IE to work properly, but now Chrome and Firefox don't like it.
UPDATE: This is a conflict between jQuery 1.3 which runs on Drupal 6 and the Wibiya toolbar which uses at least 1.4. I'm accepting #clive's answer, mainly because he's right about the fact that this is just something that I'm going to have to live with if I have to keep using Drupal 6.
My best guess would be that you're using Drupal 6 which ships with jQuery 1.2.6 (or 1.3.2 with the jQuery update module. The Wibiya baar conversely uses jQuery 1.4.2 upwards.
According to a page on the Wibiya support forums (which I'm sure you've already seen):
if page loads another version of jQuery like 1.2.6 or 1.3.2 previously, Wibiya bar's loading of its own jQ 1.4.2 does not work. No bars, nothing.
But if you load your own jQ 1.4.2 in the first place, then your bar works, despite all other Drupal functions suck like polls, votes, hierarchical select tags, nice menus, some collapsibles, etc.
There a lots of these types of problems with Drupal which is why the community comes up with workarounds and solutions: The Drupal specific Wibiya module will probably save you a lot of headaches.
UPDATE
There's a JS error on your site:
Unsafe JavaScript attempt to access frame with URL http://ar.sacherokeedev.com/auction-directory from frame with URL http://ad.doubleclick.net/adi/N1727.autoremarketing.com/B5111890.6;sz=728x90;click=http://adclick.g.doubleclick.net/aclk?sa=L&ai=B6dLCjz5qTqvUGIfN0AXN67WqBa-C-usBAAAAEAEg7ZqAFjgAWK_Q_80gYLu2moPQCrIBFGFyLnNhY2hlcm9rZWVkZXYuY29tugEJZ2ZwX2ltYWdlyAEJ2gEtaHR0cDovL2FyLnNhY2hlcm9rZWVkZXYuY29tL2F1Y3Rpb24tZGlyZWN0b3J5mAKgjQbAAgLgAgDqAhNBUl9Ib21lX0xlYWRlcmJvYXJk-ALw0R6QA4wGmAPgA6gDAeAEAaAGFg&num=0&sig=AOD64_1Xi82LSwUc1kKF0RL_orTztOMfxg&client=ca-pub-2649455708539916&adurl=;ord=1670303729?. Domains, protocols and ports must match.
Is it possible that unsafe frame attempt is stopping IE7 from processing the rest of the JS, thereby making your tabs not work?
http://digitarald.de/project/fancyupload/3-0/showcase/attach-a-file/
That's the uploader plugin I'm using.
If you go there in firefox, you'll notice you have to click "attach a file" twice before it works. It seems to work fine in every other browser (that I've tested).
it's creating a flash object, and I'm not sure how to go about making it so you only click once in FF.
I'm not familiar with mooTools, but have you tried something like this? (attempted to write it in mooTools, but have no idea what I'm doing).
$('uploadLink').addEvent('click', function(){
if(Browser.firefox) $('uploadLink').fireEvent('click');
});
or I suppose if it has to wait for the flash to be created, something like this:
$('uploadLink').addEvent('click', function(){
if(Browser.firefox){
var flashTimer = setTimeout(function(){
clearTimeout(flashTimer);
/// or however you make sure the flash has successfully been added to the page
if($('flashContainer').getElements().length) $('uploadLink').fireEvent('click');
},100);
}
});
There's always the possibility that FF's security measures won't let you do something like this (mouse interactions with flash can be potentially harmful, as flash has FS access and stuff).
Depending on what your backend is, I'm highly in favor of skipping flash for file uploads when possible. One very well written plugin for such a task is available here:
http://valums.com/ajax-upload/
Good luck!
I am trying to show an animated image while data is loading into a gridview after a button click. It works great on localhost, but when I deploy it, it doesn't. I have searched through posts, and I have not made any of what seem to be the most common mistakes ... ie. putting the updateprogress inside the updatepanel, etc. However, I am using a masterpage - but the masterpage doesn't have a scriptmanager on it. I noticed the following difference in my view source pages when I compare production to localhost .. Can anyone help me understand why the JavaScript to make this work might not be showing up in production?
On localhost (where it works) I see this at the bottom of the page:
[CDATA[
Sys.Application.initialize();
Sys.Application.add_init(function() {
$create(Sys.UI._UpdateProgress, {"associatedUpdatePanelId":null,"displayAfter":500,"dynamicLayout":true}, null, null, $get("ctl00_ContentPlaceHolder1_UpdateProgress1"));
});
In production (where it does NOT work), this is all I see:
Sys.Application.initialize();
I was having really hard time after converting my project from VS2008 to VS2010. The UpdateProgress stopped working suddenly, which was fine in VS2008. Spending a whole afternoon to search the answer and experimenting this and that, finally I found what went wrong from Scott Gu's posting.
It was an automatically generated web.config entry 'xhtmlConformance mode="Legacy"'.
After disabling this, it started to work again. May be not the case for you but just for guys struggling with the same problem.
Happy coding
This may not be your ideal solution, but you could show() or hide() your animated image just using javascript. Using the following javascript functions (and getting rid of the UpdateProgress control) should do the trick.
Sys.WebForms.PageRequestManager.getInstance().add_beginRequest(beginRequest);
Sys.WebForms.PageRequestManager.getInstance().add_endRequest(endRequest);
function beginRequest(sender, args) {
document.getElementById('myImageElement').style.display = 'block';
}
function endRequest(sender, args) {
document.getElementById('myImageElement').style.display = 'none';
}
Keep in mind this will happen for every postback, you may need to use the sender parameter to deduce which element called the postback and only perform the display when the correct updatepanel is hit. These events are fired at the beginning and end (respectively) of each UpdatePanel postback. Good luck.