I'm trying to get Enquire.js working for legacy browsers. I'm using the Deep support method from the docs:
Modernizr.load([
{
test: window.matchMedia,
nope: "media.match.min.js"
},
"enquire-2.0.0.min.js",
"plugins.js", // jquery plugins
"main.js" // enquire-triggered functions + general code
]);
The problem with this is I am using Modernizr+Respond from initializr.com, so the test always passes. This triggers a JS error in enquire.js in IE8/9.
By removing respond.js and just using plain Modernizr the test fails, Media.match loads, and the JS error is solved. However, I lose my Media Query support in IE8.
What's the best method to get everything working together? I have tried loading respond.js at the same time as Media.match via Modernizr. If I load it first, I see the same JS error as before. If I load it second, media queries don't work. I've also tried just loading that INSTEAD of Media.match, but the JS error returns.
Thanks.
EDIT:
Shortly after posting this I rolled back to enquire 1.5.6, used Respond.js, the shouldDegrade option, and no Modernizr tests. No JS errors in IE8/9, and everything seems to be working fine so far.
I am still interested to know if there's a way to get this working with 2.0, or if I should stick with the 1.5.6 for now?
I ran into the same problem with Enquire v2.0.2. My workaround was to remove the inclusion of matchMedia from respond.js, and then load media.match and enquire.js after loading respond.js. I haven't tested this with modernizr yet, but I was able to get media query support and enquire.js to work in IE7 and 8 with no JS errors.
I guess the actual problem is that in respond.js you do have the matchMedia polyfill but without the matchMedia.addListener plugin. So the modernizr test for plain matchMedia succeeds but then results in the error you probably get with enquire (Object doesn't support this property or method).
I myself wouln't like to customize respond.js not to include matchMedia but rather just load the matchMedia.addListener plugin separately after respond.js.
Tim,
A little late but did you see this yet? I think it's what you are looking for.
enquire.js legacy support
Related
The process for writing multiple windows tests described in TestCafe documentation seems pretty straightforward:
await t.openWindow('https://url.com/addnewproperty')
or even
const initialWindow = await t.getCurrentWindow()
should do it. However, every time I use any of the Window Management methods I get the errors:
TypeError: t.openWindow is not a function and cannot do anything about it.
Does anyone know what am I doing wrong and how to solve the issue?
TestCafe version 1.9.4
The problem was in different versions of Test Cafe used between main codebase and one of the underlying packages. Alex Kamaev answer was a correct one
I've working on modification of the 'shoutem.notification-center' extension using as a guide this tutorial and I'm having some issues.
At first I tried to use the Extend the extension approach, but like I've posted on this issue, didn't quite work.
So I've tried the Directly modify approach, which works fine on my local phone, but once I use the command shoutem push to send my modifications to the server, the instance on Appetize never stops the 'Building your application' message.
The major problem is that there's no error code or feedback.
That was not the first time that happened, I had the same issue modifying other extensions. Any idea why this is happening?
The issue is likely one of two things.
New native dependencies were added that the Builder preview cannot process due to it's predefined binary.
Your directly modified extension works locally, but not on the Builder because locally it's path is still AppName/extensions/shoutem.extName, but on the Builder it's AppName/extensions/yourDevName.extName, so it fails.
The first one can be resolved by either using a non-native solution as a replacement for the native dependency you were using, or to simply use a local emulator for previewing purposes.
The second can be resolved by making sure all extensions that reference the one you directly modified are edited to now reference your new directly modified extension instead of shoutem.extName.
If you could shoot me your app ID in a comment I can let you know which one it is and what the best steps to fix it would be.
I have update Ember-data to 1.0.0-beta.19 and now store.find('events') resolved promise returns DS.INTERNALMODEL instances, instead of DS.MODEL. With Ember-data 1.0.0-beta.18 it was working fine. Any ideas?
UPDATE
At the end i found out that somewhere in my app code i was using Ember-data internal code like store.find('events.content'), causing an exception. The debugger was not so helpful tracing it, but removing this fixed my issue.
This is a bug, if the promise resolves with DS.InternalModel, those are only for internal use of Ember-Data and shouldn't be exposed to user code. Please file a bug if this is still a problem
This is on purpose. It's noted in the chanelog:
#3094 Lazily materialize DS.Models for app code, use InternalModel inside ED otherwise
It should work largely with no issues. Are you having issues with it?
You can access the DS.Model using InternalModel.record
I'm using Zombie.js for testing with Cucumber-js, and I can't seem to get my client side scripts to run.
Visiting the page:
this.browser.visit("http://localhost/boic",function(e, browser,status,errors){
console.log('status',status);
console.log('error',errors);
console.log('console',browser.text("H1"));
});
Returns a status of 200, no errors, and displays the H1 text correctly. However, if I include a script to change the H1 code in the page:
<script>
$('H1').html('hello world');
</script>
The H1 text remains unchanged, and no global variables are accessible via browser.window...
thanks!
Did you load jQuery in your page before the script is called?
there is also the runScripts browser option but that defaults to true.
But I'm gonna recommend running an external phantom.js process and going through the webdriver interface. Just because I spent 6 months trying to get zombie to do what I wanted and phantomjs made it all easy. http://phantomjs.org/release-1.8.html https://github.com/LearnBoost/soda
I agree w/ Jon Biz. Zombie is difficult to work with. Many sites that use JS libraries that might contain minor errors cause it to crash (I think node fails) when the zombie browser encounters them - if you have the runScripts option set. This makes it very hard to use for any application/site that requires external JS - ie most of them.
I also recommend switching to Phantomjs.
I'm trying to follow the basic cometd example here: http://dojotoolkit.org/reference-guide/1.7/dojox/cometd.html
It's using the old module loader so I tried the equivalent as follows:
require(["dojo/ready","dojo/io/script","dojox/cometd","dojox/cometd/callbackPollTransport"], function(ready, dontcare, cometd) {
ready(function(){
cometd.init('http://localhost:8080/MyCometD/cometd');
comted.subscribe("/test", function(msg){
console.debug(msg);
});
});
});
This doesn't work and I think it has to do with loading modules - there is some sort of silent error as the code within the ready function does not execute at all. What I found is that when the "dojox/cometd" require statement is present, the code within the ready function does not execute.
Running example: http://jsfiddle.net/Q9W8f/2/
Example with dojox/comted removed: http://jsfiddle.net/mMs2h/4/
I haven't worked with the new module loader that much so I bet I just have some simple misconception.
Help!
It seems like youre correct and that there is a 'wait-loop' for a module requirement that never gets loaded. This may be any of the requirements inside dojox.cometd and you'd need to rewrite the codebase for a fix.
I have had similar issue with the RollingListPane, also in dojox repository - and the developers are saying 'we are 100% AMD compliant with 1.7' however the X in dojox is short for experimental. The developement of dojox modules is not done by the core djtk team and there are still glitches..
Try for starters to avoid using CDN which has performed a >>built macro on every single module. This tends to fail at times whilst using AMD. Instead download the tarball and use a local copy - Not compressed (dojo-release-1.7.2-src)
You can find the hello world example in cometD and ExtJs at following link:
http://jksnu.blogspot.in/2013/08/network-reliability-by-cometd-hellow_16.html