We Keep Coding

Object doesn't support property or method 'ExecWB' when trying to call a print preview dialog in IE9

I am writing a web application for IE9 and I need to open the Print Preview dialog (not the window.print(), but the one where they can set the margins etc.)
I found this code in this question - Open another page or image in print Preview:
function PrintPreview()
{
var OLECMDID = 7;
/* OLECMDID values:
* 6 - print
* 7 - print preview
* 0 - open window
* 4 - Save As
*/
var PROMPT = 1; // 1 PROMPT USER 2 DON'T PROMPT USER
var WebBrowser = '<OBJECT ID="WebBrowser1" WIDTH=0 HEIGHT=0 CLASSID="CLSID:8856F961-340A-11D0-A96B-00C04FD705A2"></OBJECT>';
window.document.body.insertAdjacentHTML('beforeEnd', WebBrowser);
WebBrowser1.ExecWB(OLECMDID, PROMPT);
WebBrowser1.outerHTML = "";
}
However, this line fails:
WebBrowser1.ExecWB(OLECMDID, PROMPT);
The error message in both IE9 and IE11 is this:
"Object doesn't support property or method 'ExecWB'"
Update: more testing showed that the code works in some IE9/IE11 browsers (such as on my machine) but doesn't work on the browser inside an Azure VM and on my customer's configuration.
WebBrowser1 is not null and has a lot of properties and methods, such as the correct classid, but doesn't have the ExecWB() method.

Turns out that the code doesn't work if this option is set to "Disabled" in IE Tools => Internet Options => Security => Security Settings:

Firefox Add-on SDK : equivalent to Chrome "chrome_url_overrides"

I'm making add-on modules for several browsers, including Chrome and Firefox.
I just did what I want with Chrome : overriding new tab url to load a HTML file with the manifest.json. Pretty simple. (Now I'm able to copy paste again :)) :
...
"chrome_url_overrides" : {
"newtab": "override.html"
},
...
When the user create a new blank tab, it overrides the default page and loads the file I want : override.html, with the same behavior (no URL in the address bar).
But now, I want to do the same thing with Firefox using Add-on SDK. I tried using browser.newtab.url :
var { get, set } = require("sdk/preferences/service");
var { when: unload } = require("sdk/system/unload");
var oldValue = get("browser.newtab.url");
set("browser.newtab.url", 'http://www.example.com');
// Restore old setting when unload
unload(function() {
set("browser.urlbar.autoFill", oldValue);
});
It works, but I really would be able to load an HTML file instead giving it a new URL (the code would be more maintainable) and keep a clean address bar.
Any ideas ?

IE 9 and 10 yield unexpected and inconsistent MediaError's

We have a set of HTML blocks -- say around 50 of them -- which are iteratively parsed and have Audio objects dynamically added:
var SomeAudioWrapper = function(name) {
this.internal_player = new Audio();
this.internal_player.src = this.determineSrcFromName(name);
// ultimately an MP3
this.play = function() {
if (someOtherConditionsAreMet()) {
this.internal_player.play();
}
}
}
Suppose we generate about 40 to 80 of these on page load, but always the same set for a particular configuration. In all browsers tested, this basic strategy appears to work. The audio load and play successfully.
In IE's 9 and 10, a transient bug surfaces. On occasion, calling .play() on the inner Audio object fails. Upon inspection, the inner Audio object has a .error.code of 4 (MEDIA_ERR_SRC_NOT_SUPPORTED). The file's .duration shows NaN.
However, this only happens occasionally, and to some random subset of the audio files. E.g., usually file_abc.mp3 plays, but sometimes it generates the error. The network monitor shows a successful download in either case. And attempting to reload the file via the console also fails -- and no requests appears in IE's network monitor:
var a = new Audio();
a.src = "the_broken_file.mp3";
a.play(); // fails
a.error.code; // 4
Even appending a query value fails to refetch the audio or trigger any network requests:
var a = new Audio();
a.src = "the_broken_file.mp3?v=12345";
a.play(); // fails
a.error.code; // 4
However, attempting the load the broken audio file in a new tab using the same code works: the "unsupported src" plays perfectly.
Are there any resource limits we could be hitting? (Maybe the "unsupported" audio finishes downloading late?) Are there any known bugs? Workarounds?
I think we can pretty easily detect when a file fails. For other compatibility reasons we run a loop to check audio progress and completion stats to prevent progression through the app (an assessment) until the audio is complete. We could easily look for .error values -- but if we find one, what do we do about it!?
Addendum: I just found a related question (IE 9/10/11 sound file limit) that suggests there's an undocumented limit of 41 -- not sure whether that's a limit of "41 requests for audio files", "41 in-memory audio objects", or what. I have yet to find any M$ documentation on the matter -- or known solutions.

Have you seen these pages on the audio file limits within IE? These are specific to Sound.js, but the information may be applicable to your issue:
https://github.com/CreateJS/SoundJS/issues/40 ...
Possible solution as mentioned in the last comment: "control the maximum number of audio tags depending on the platform and reuse these instead of recreating them"
Additional Info: http://community.createjs.com/kb/faq/soundjs-faq (see the section entitled “I load a lot of sounds, why am running into errors in Internet Explorer?”)

I have not experienced this problem in Edge or IE11. But, I wrote a javascript file to run some tests by looping through 200 audio files and seeing what happens. What I found is that the problem for IE9 and IE10 is consistent between ALL tabs. So, you are not even guaranteed to be able to load 41 files if other tabs have audio opened.
The app that I am working on has a custom sound manager. Our solution is to disable preloading audio for IE9 and IE10 (just load on demand) and then when the onended or onpause callback gets triggered, to run:
this.src = '';
This will free up the number of audio that are contained in IE. Although I should warn that it may make a request to the current page the user is on. When the play method in the sound manager is called again, set the src and play it.
I haven't tested this code, but I wrote something similar that works. What I think you could do for your implementation, is resolve the issue by using a solution like this:
var isIE = window.navigator.userAgent.match(/MSIE (9|10)/);
var SomeAudioWrapper = function(name) {
var src = this.determineSrcFromName(name);
this.internal_player = new Audio();
// If the browser is IE9 or IE10, remove the src when the
// audio is paused or done playing. Otherwise, set the src
// at the start.
if (isIE) {
this.internal_player.onended = function() {
this.src = '';
};
this.internal_player.onpause = this.internal_player.onended;
} else {
this.internal_player.src = src;
}
this.play = function() {
if (someOtherConditionsAreMet()) {
// If the browser is IE, set the src before playing.
if (isIE) {
this.internal_player.src = src;
}
this.internal_player.play();
}
}
}

Multiple mp4 requests in Chrome stuck in 'pending'

I have a list of films (buttons) which - when a user clicks - performs an AJAX request to update the video tag's source attribute. Before loading the new video (.load()), the video element is cloned, removed, then re-inserted into the DOM (this is to fix a Safari bug). See code below:
//load in new paths
var contentVideos = $("#projectsMedia video source");
contentVideos.each(function () {
if ($(this).attr("src").lastIndexOf("mp4") !== -1) {
$(this).attr("src", videoPath + ".mp4");
} else if ($(this).attr("src").lastIndexOf("ogv") !== -1) {
$(this).attr("src", videoPath + ".ogv");
} else if ($(this).attr("src").lastIndexOf("webm") !== -1) {
$(this).attr("src", videoPath + ".webm");
}
});
//clone vid, delete, reload for safari bug
var clonedVid = $("#projectsMedia video").clone();
$("#projectsMedia video").remove();
clonedVid.insertAfter($("#projectsMedia h1"));
$("#projectsMedia video")[0].load();
This works fine for all browsers, but Chrome seems to be throwing a spanner into the works. When the new path is put into the src attribute and the video is loaded, Chrome takes anywhere between 2 second to infinity to load the video.
Opening the dev console, I found that the mp4 file is being downloaded multiple times (an apparent feature of Chrome), and the requests are stuck in pending for an indefinite amount of time and the video rarely loads within 10 seconds. See screenshot.
Another curios behaviour in Chrome is that on a page refresh (or button-click to perform a new AJAX request), if the dev console is not open, then opening it will force the mp4 to load, and it works fine.
Does anyone know of a solution to this?

addthis_widget.js throwing Cannot read property '_pmh' of null error on Android and Chrome

I am using a JavaScript error logging tool to log any JavaScript errors on my mobile site and I am seeing a large number (22,000 in under a month) of this error:
Uncaught TypeError: Cannot read property '_pmh' of null
I can see from the addthis_widget.js code that it is originating from that script.
I can also tell that it only affects mobile Android and Google Chrome browsers, these in particular:
Android 4, Android 4.1, Android 4.2, Chrome 11, Chrome 18, Chrome 25, Chrome 26, Chrome 27, Chrome Mobile 18, Chrome Mobile 25, Chrome Mobile 26
I am using the following external JavaScript include:
http://s7.addthis.com/js/250/addthis_widget.js#username=xa-4b6adff375a64db9
and have the following configuration object set:
<script type="text/javascript">
var addthis_config = {
data_ga_property: 'UA-18721873-1', // real GA profile hidden for privacy purposes
data_ga_social: true
};
</script>
Is there anything I can do to prevent this error from occuring so many times on these browsers?

I have located the cause of this issue and it is down the following code.
if (window.addthis) {
window.addthis = null;
window._adr = null;
window._atc = null;
window._atd = null;
window._ate = null;
window._atr = null;
window._atw = null;
}
This was an attempt to cleanup the objects lying around when moving between pages dynamically to prevent memory issues.
addThis now provide support for this problem, their support department sent me the following link:
http://www.addthis.com/blog/2013/05/07/a-brief-history-of-using-addthis-dynamically/#.Uklx4RCKyas
and the following explanation/information:
Along with other information from my peers and such, I've come up with
the proper code which should be executed when moving from virtual page
to virtual page such as in your mobile application. Rather than
nulling any of the AddThis related objects, they must be left alone.
When the page URL or Title (or any other AddThis configuration option)
that you want to be used by our buttons changes, you should execute
our method:
addthis.update(type, key, value)
It takes the three parameters: type, key, value.
Type is either "share" or "config". The key is the same key you would
set according to our API documentation. What you likely need to know
are just the two keys: "url" and "title". The value is of course the
value you want those options to have.
After you have updated all of the options you need to update using
that method, you need to invoke this method:
addthis.toolbox(cssSelector)
The cssSelector is usually going to be ".addthis_toolbox" but if for
some reason you don't want to refresh all of your toolboxes, you can
be more specific about it.
Once you have made those changes to your code, I believe that our
tools will work properly for you and that there will be no more "null
object" related javascript errors.
You can look at this JSFiddle to see an example of dynamically
changing content: http://jsfiddle.net/j5addthis/r6Utv/

I'm having the same issue, but it appears that there was, at one point, a fix to your specific case above by simply upgrading the script that you're using from addthis to version 3.0 by changing this:
http://s7.addthis.com/js/250/addthis_widget.js#username=xa-4b6adff375a64db9
To this:
http://s7.addthis.com/js/300/addthis_widget.js#username=xa-4b6adff375a64db9
Read more here: http://support.addthis.com/customer/portal/questions/1021465-addthis-widget-js-throwing-cannot-read-property-pmh-of-null-error-on-android-and-chrome
Note though, as I mentioned above, my issue continues to persist even with version 3.0 despite the AddThis help desk stating that should work.