On Wednesday the AJAXy CRM system I maintain broke for many users, because Firefox started reporting "Use of XMLHttpRequest's timeout attribute is not supported in the synchronous mode in window context" . The other major browsers still work fine so as a workaround I have advised people not to use Firefox.
From what I understand synchronous requests are A Bad Thing, so I can only assume some recent update to Firefox has stopped it from accommodating Bad Things. All previous discussions (here and on the web) imply the use of the timeout attribute with synchronous XMLHttpRequest objects shouldn't work at all, which leads me to wonder why it apparently does (except on Firefox as of Wednesday).
Are the other browsers / old Firefox actually implementing timeout behaviour where they "shouldn't", or do they just ignore the exception and continue execution (rather than bailing out like new Firefox)?
EDIT: I can't get to the code right now but it was along the lines of:
if (c.somekindoftimeouthandler !== "unassigned" && this.timeout) {
c.timeout = this.timeout
//more stuff about the handler etc...
}
where 'this' is come complicated thing presumably inherited from XMLHTTPRequest and 'c' is a specific object referring to the specific AJAX request, or something. I'll come clean that I know little about both Javascript and this specific Sugar-based CRM, but the essence of the code was simple. It was a generic object-oriented way to make requests, and this particular 4-lines or so dealt with when the request timed out. I get the impression this was an abstract base from which specific requests (or requesting entities) were supposed to specialise. The Firefox Javascript engine chokes on the this.timeout.
I believe the thrust of my question is more general though - given the 'badness' of using timeout for synch XHR, how do the various browsers deal with it?
IE allows 'timeout' to work for sync XHR. If the timeout time is reached, it'll throw an exception from send(), I believe.
Firefox implemented exactly what the XHR spec says: timeout is supported on async XHR but not supported for sync XHR (throws if you try to set it).
Other browsers (and old Firefox) don't support timeout at all; they don't even have the property. Since your script is sniffing for whether the property is there, it doesn't even try to set timeout in those other browsers, which is why it works there: your script is not trying to do bad things, so those browsers don't end up throwing an exception.
So all that changed is that Firefox added support for the timeout property, but instead of doing what IE does it implemented what the spec says to do. And your script was assuming that any browser that implements the property will behavior the way IE does...
Related
I'm using the Firefox permissions API documented HERE
I'm having a problem with the request method, wherein all of my permissions requests result in:
Error: permissions.request may only be called from a user input handler
You can produce this in firefox by debugging any addon or extension and entering browser.permissions.request({origins: ["https://google.com/*"]}) into the console.
I find it hard to swallow that a permissions request must always have a user input event callback in the parent stack trace. I'm using Vue.js, and my Permissions are due to user interaction, but my user interactions are decoupled from the events they trigger.
What counts as a user input handler?
Why does it work like this?
Is there a good work-around?
Is there a good work-around"
I'd like to add onto Andrew's answer with some code examples.
As it turns out, promise chains destroy the browser's notion of what is and isn't triggered by a user input handler. Take the code below, for example:
document.getElementById('foo').addEventListener('click', event => {
browser.permissions.request({origins: ["https://google.com/*"]})
})
This code works as expected. I originally assumed that it was Vue.js's unique event handling framework that was eating my "browser events", such as when you do <div #click="somefunc"></div>. This actually works just fine, as long as you put your permissions request in somefunc.
Now it gets fun. If you replace your permissions request with a promise that resolves and then does a permissions request, VIOLA!
Promise.resolve('foobar').then(foobar => {
browser.permissions.request({origins: ["https://google.com/*"]})
})
Results in:
Error: permissions.request may only be called from a user input handler
Why does this happen?
I'm going to guess it has to do with stack traces. Firefox can't detect that a permission came from a stack with a user input event at the root if the permissions request happens in a promise chain.
I consider this to be a pretty egregious design choice. My app is large (>4K LoC) and to keep it simple I rely on promise chains to keep the spaghetti away. This has crippled my ability to write clean code, and as a result, I've moved from asking for optional_permissions and then prompting the user for permissions only when needed to just being overly permissive at the time of installation.
GG, Firefox.
What counts as a user input handler?
A DOM event handler that corresponds to user input (e.g., target.addEventHandler("click", ...) or a WebExtension event listener that corresponds to user input (e.g., browser.browserAction.onClicked.addListener(...)
Why does it work like this?
Partly for basic UX (if a user is not directly interacting with an extension and a prompt for the extension suddenly prompts up, it can easily confuse them), but also to avoid clickjacking attacks where the prompt is put up at a carefully chosen moment when the user is likely to be expecting some unrelated prompt.
Is there a good work-around?
I think just organizing your code so that you request permissions from a user input handler is probably your best bet.
So on one of our recent launches we had a lot of events that we were observer such as controller_action_predispatch. Once the site went live we started noticing that our observers were never getting called for those. After a little investigation one of our developers found this block of code in Mage_Core_Model_App around line 292
if ($this->_cache->processRequest()) {
$this->getResponse()->sendResponse();
} else {
$this->_initModules();
$this->loadAreaPart(Mage_Core_Model_App_Area::AREA_GLOBAL, Mage_Core_Model_App_Area::PART_EVENTS);
if ($this->_config->isLocalConfigLoaded()) {
$this->_initCurrentStore($scopeCode, $scopeType);
$this->_initRequest();
Mage_Core_Model_Resource_Setup::applyAllDataUpdates();
}
$this->getFrontController()->dispatch();
}
As you can see if $this->_cache->processRequest() that is true which it is when full page cache is enabled you never get to the dispatch. The developer did find http_response_send_before which gets call either way but it seems to me like this is a bug or you should never ever use those controller dispatch events for anything if you have full page caching enabled. Any thoughts?
Given the nature of the full page caching, I'd call this "works as intended". While it can be a little strange not to have some events firing, they had to pick a line and this one makes sense to me, especially since the controller is never really dispatched.
You should use those controller dispatch events for anything that affects the page (as it still needs to be generated), but if you are using it for tracking and such, no it would not be appropriate.
See here if you want to learn how Caching works with Magento Enterprise
http://magentophp.blogspot.com/2011/02/magento-enterprise-full-page-caching.html
The only reliable event to listen for with and without Full Page Cache enabled is http_response_send_before.
controller_front_send_response_before
This event will be fired irrespective of FPC enabled
I have written a Firefox extension that catches when a particular URL is entered and does some stuff. My main app launches Firefox with this URL. The URL contains sensitive information so I don't want it being stored in the history.
I'm concerned about the case where the extension is not installed. If its not installed and Firefox gets launched with the sensitive URL, it will get stored in history and there's nothing I can do about it. So my idea is to use a bookmarklet.
I will launch Firefox with "javascript:window.location.href='pleaseinstallthisplugin.html'; sensitiveinfo='blahblah'".
If the extension is not installed they will get redirected to a page that tells them to install it and the sensitive info won't get stored in the history. If the extension IS installed it will grab the information in the sensitiveinfo variable and do its thing.
My question is, can the bookmarklet call a method in the extension to pass the sensitive info (and if so, how) or can the extension catch when javascript is being called in the bookmarklet?
How can a bookmarklet and Firefox extension communicate?
p.s. The alternative means of getting around this situation would be for my main app to launch Firefox and communicate with the extension using sockets but I am loath to do that because I've run into too many issues over the years with users with crazy firewalls blocking socket communication. I'd like to do everything without sockets if possible.
As far as I know, bookmarklets can never access chrome files (extensions).
Bookmarklets are executed in the scope of the current document, which is almost always a content document. However, if you are passing it in via the command line, it seems to work:
/Applications/Namoroka.app/Contents/MacOS/firefox-bin javascript:alert\(Components\)
Accessing Components would throw if it was not allowed, but the alert displays the proper object.
You could use unsafeWindow to inject a global. You can add a mere property so that your bookmarklet only needs to detect whether the global is defined or not, but you should know that, as far as I know, there is no way to prohibit sites in a non-bookmarklet context from also sniffing for this same global (since it may be a privacy concern to some that sites can detect whether they are using the extension). I have confirmed in my own add-on which injects a global in a manner similar to that below that it does work in a bookmarklet as well as regular site context.
If you register an nsIObserver, e.g., where content-document-global-created is the topic, and then unwrap the subject, you can inject your global (see this if you need to inject something more sophisticated like an object with methods).
Here is some (untested) code which should do the trick:
var observerService = Cc['#mozilla.org/observer-service;1'].getService(Ci.nsIObserverService);
observerService.addObserver({observe: function (subject, topic, data) {
var unsafeWindow = XPCNativeWrapper.unwrap(subject);
unsafeWindow.myGlobal = true;
}}, 'content-document-global-created', false);
See this and this if you want an apparently easier way in an SDK add-on (not sure whether SDK postMessage communication would work as an alternative but with the apparently same concern that this would be exposed to non-bookmarklet contexts (i.e., regular websites) as well).
I'm attempting to port over an Internet Explorer plugin to Firefox, but I'm not sure where to look for what I need.
Basically I need to be able to filter all content that is received by the browser with a certain Content-Type header. I tried implementing a stream converter, and this works, but only for the top-level document in the page, frame, or iframe. I had the same problem with IE, and getting around it was really hacky, and since I would ideally like this to be cross platform I would really like to be able to do this in Firefox without resorting to vtable hacks.
The content is served compressed with a proprietary compression format. So I need to receive the data, decompress it, and change the Content-Type back to what the original uncompressed file should have.
If there is a way to just filter all data received, that would probably be acceptable, I could handle parsing the header myself.
Thanks
I think I may have found what I needed. I came across this link which is used for tracing HTTP calls: http://blues.ath.cx/firekeeper/resources/http_tracer.html
There seems to be some problems with the JavaScript implementation for some reason, and I'm not a JavaScript guru to figure it out, but I've implemented it in C++ and initial results suggest that I should be able to modify it for my needs.
Basically we're replacing the nsIHttpProtocolHandler service with our own implementation, which keeps a reference to the initial implementation. When a call is made to the service, we just proxy it over to the saved original implementation. Then we provide our own implementation of nsIHttpChannel and nsIStreamListener which we use as proxies too.
Again we proxy most of the calls back off to the original handlers. But in OnDataAvailable, instead of passing the data on to the underlying nsIStreamListener, we save it using nsIStorageStream. Then in OnStopRequest, after we've gotten all of the data, we can decompress it and then call OnDataAvailable on the original handler, followed by OnStopRequest.
It has worked on some small simple tests so far, but I'll have to put it through some more rigorous tests... I'll also have to figure out if I can do the same thing with HTTPS.
The biggest problem I see at the moment is that it relies on some unfrozen interfaces such as nsIHttpChannelInternal. Can't be helped though as far as I can tell, and my version compatibility requirements are pretty small, so I can live with it if I have to.
In the meantime, if anybody has any other suggestions, I'm all ears :D
I have a couple of queries for a web site that take a long time to run due to the data model and the amount of data held in the tables. So far I've been running them manually against the database to avoid any timeout issues etc.. however the site owner has asked for these to be made available on the site so he can get the query results.
I had thought of doing this via a .NET web service and having the classic ASP page call this asynchronously. The web page would just initiate the process and before redirecting the user to another screen. The web service would then run the query and email the user the results in a CSV.
However, I can't seem to get this to work. The service runs ok if I invoke it through the screen in IE but calling it through an Ajax call in ASP seems to be an issue - no error is generated but neither is the CSV file created.
I've enclosed the classic ASP code below. The service only has one method with a parameter of the name email which is of the type string. Can anyone see anything wrong with it? Also, this the best way to be doing this or should I be thinking of another approach?
CODE
<%
message = "http://wwww.example.com/service/query.asmx/GetResults?email=test"
set req = server.createobject("MSXML2.XMLHTTP")
With req
.open "GET", message, False
.setRequestHeader "Content-Type", "text/xml"
.send
End With
works = req.responseText
response.redirect "http://www.bbc.co.uk"
%>
The idea of asynchronously requesting the work and arranging for its later delivery seems very reasonable to me. I don't speak ASP well enough to know what's wring with your attempt, but is that really an asnch call you have there? Would the seb service also suffer from an HTTP connection timeout?
My approach would have been for an Ajax request to place a request on a queue and return, no need for a redirect, you're still on the page where the user makes the request, your JavaScript could just acknowledge that the request was sent. Alternatively, your more traditional "submit a page, stash the request, display another page" appraoch can work, but the the stashing is just to put the request on a queue.
An advantage of the queueing approach is that by controlling the number of daemons we can get controlled parallelism in servicing the requests - avoid overloading the DB. Also the queues can persist and allow a leisurely delivery of the responses.
I assume that MS queues then let you have a daemon processing the reuquest and delivering the responses. Clearly email works, but strikes me as a tad unfriendly. With Ajax style interfaces it would be quite easy to invisibly poll for the status of requests and obtain the results when they are ready, or even to use Comet-style push delivery of the responses.
The problem here, as djna noted, is that you are not calling a callback function.
Due to the asynchronously aspect of Ajax, you have set up a callback function that will be executed when the Ajax call ends.
Long story short:
Call the webservice from a javascript function, preferably using JQuery to avoid cross browser incompatibilities
Code:
<div id="results">Processing query. Please wait</div>
<script type="text/javascript">
$(document).ready(function(){
$("#results").load("http://wwww.mywebsite.com/service/query.asmx/GetResults?email=test&Rnd=" + Math.random().toString());
});
</script>