I know this question has been answered before, but the answer given is not the complete story:
I went into Firefox's Options->Content and removed all languages except German/Germany, and navigator.language hasn't changed - it's still en-GB (I'm in the UK).
I'm told if I get the German Firefox INSTALL it will work, but I shouldn't need to do that, right?
The useragent string still contains en-GB, too; but the accept-language on HTTP headers IS set correctly. So this seems to be a bug in Firefox, I spent a bit of time wading through their bugzilla, but I can't see this exact bug logged, though to me it seems a pretty huge oversight?
Both navigator.language and the HTTP User-Agent header use the value of the preference "general.useragent.locale", which is hard-coded in intl.properties to the locale of the Firefox build you downloaded:
http://mxr.mozilla.org/mozilla-central/source/toolkit/locales/en-US/chrome/global/intl.properties#8
Or for your en-GB build:
http://hg.mozilla.org/l10n-central/en-GB/file/88dd673c01f1/toolkit/chrome/global/intl.properties#l8
If you'd like to change it for your build, just load about:config, find general.useragent.locale, double-click it, and change the value.
I would recommend to use a Firefox Add-on for this task. Simple Locale Switcher, Locale Switcher or Quick Locale Switcher etc. (* Caution some of this Add-ons may contain ad ware or may not work if you've just updated firefox).
*Another solution is to download a different old firefox version using the language/locale. (Caution) You need and install it in a different folder so you won't overwrite your existing version. Download here I'm using firefox 28 in Spanish. I disabled updates and I rejected using it as my default browser. Only one firefox version should be running at the same time if you do this.
I would assume that navigator.language returns it's interface language (I assume is GB English), not one that it wants documents in. User-agent string too report which version of firefox was downloaded.
Accept-language is what destination server should check.
I consider this behavior of his quite correct (assuming that it's interface (menus and such) are really in GB english).
in firefore, about:config, modify the value of "intl.accept_languages", to your required locale, let's say de-DE will do.
If you want the Accept-Language value, you can't retrieve if using client-side JavaScript. You'll have to get it from your server.
If you really want this value in client-side JavaScript, then read it on the server and write it back to the client:
<script type="text/javascript">
// setting the accept language HTTP header value
// in client-side JavaScript from PHP
var acceptLanguage = '<?php echo $_SERVER["HTTP_ACCEPT_LANGUAGE"]; ?>';
</script>
Related
In Firefox extension I need to open a specific webpage in new tab and I need to send POST data to it. I have full control over target webpage (my server).
What I've tried so far is..
This is actually sending GET with no data (but works in Chrome. Possibly a CSP limitation..)
Chrome Extension Development - POST to new tab
Instead of using generated FORM on the webpage, i tried XmlHttpRequest. I can successfully send the post request and get the answer, but I only get the response as plain text and can't open it in current window (I only get static content without working scripts upon inserting it to the page's BODY)
I played with the XHR response a bit and tried:
document.open();
document.write(xhr.responseText);
but I get "Loading of source self ("script-src") was blocked due to CSP".
So I tried to find the answer how to set CSP and headers and I inserted a header:
<meta http-equiv="Content-Security-Policy" content="script-src 'self'">
on both local and the remote page. It did not help, though.
Does anyone know a solution please?
When you add "script-src 'self' you are allowing script files to be accessed within the same domain, but inline-scripts (as in <script> ... </script>) will still be disallowed.
To allow inline scripts, you can add the 'unsafe-inline' part after 'self'. But this is not recommended, because it defeats a large part of what CSP is trying to do (prevent XSS attacks). You should add a base64 sha256 hash of each inline script instead (assuming it is a static unchanging script) with the sha256 prefix. e.g. 'sha256-xxxxORCihnocralsomehashgoeshere').
However, if you aren't using inline scripts, maybe the browser is smart enough to know that the script you're running came from a different domain and is blocking it. If so, try adding the specific domain in the request on your requesting page. For instance, if you are posting to 'example.com', your CSP will look like this:
content="script-src 'self' 'example.com'"
Finally, You should know that the preferred CSP mechanism is by HTTP Header, and some browsers may not support it. It also has additional restrictions in that it can't be used in frame-ancestors and can't hook up to report-uri.
Extension Link: https://www.dephormation.org.uk/?page=81
This plugin is great. It has one problem though, on pages that use AJAX to make http requests, it switches the user agent for each request and confuses many ajax applications.
What I want to do is figure out where the preferences for this plugin are saved. Particularly, where all the User-Agent Strings that are currently being used are located. I would like to do this so that I could edit these settings outside of firefox before I open the browser so as to "hot swap" one user agent string for each browsing session at a time. I have looked through all kinds of .sqlite databases in my firefox profile but still haven't found the information.
I am using Watir-Webdriver with ruby to application test.
As Mr Palant said... simply changing general.useragent.override would achieve what you want.
Type about:config in the address bar, accept the warning, and filter on useragent and you'll see the setting.
I gather (but haven't tested) this preference may not affect the user agent presented to client side Javascript code. So if your Ajax code references navigator.useragent you might find the real user agent is returned despite your override setting.
Pete (author of SecretAgent).
www.secretagent.org.uk
PS See also
https://developer.mozilla.org/en/Document_Object_Model_%28DOM%29/window.navigator.userAgent
You don't need an add-on for that - changing general.useragent.override preference (create it if not present yet) is enough to set a different user agent string. In Firefox you can do it under about:config, when Firefox isn't running you can add this preference to the file prefs.js in the Firefox profile.
The problem: toggle javascript support without restarting firefox (nor resorting to different driver) during cucumber test run.
If Firefox's prefutils were exposed to javascript in a web page, that would make it possible. But it is not the case.
So, is there a plugin that does it? Or is there another way to solve the problem? Or is there a good tutorial (that highlights the exposing bit) on how to make such a plugin?
Edit
On a second thought, how would javascript be of any help once it is disabled? Probably the whole idea is a bit screwed.
I assume that your tests run with normal web content privileges. In that case, they aren't going to be able to affect browser settings such as whether JavaScript is enabled (I assume that's what you mean by "toggle JavaScript support").
I'd implement a simple XPCOM component with a method to turn JS support on and off (by setting the appropriate pref). You can expose it as a JavaScript global property so that your tests can access it. See Expose an XPCOM component to javascript in a web page for more details. Package your component in an extension and make sure it is installed in the Firefox instance where your tests are running.
If you want to access the preferences API directly from your content script, you can add the following prefs to Firefox, either in about:config or by adding the following lines to prefs.js in your profile directory:
user_pref("capability.principal.codebase.p1.granted", "UniversalXPConnect UniversalBrowserRead UniversalBrowserWrite UniversalPreferencesRead UniversalPreferencesWrite UniversalFileRead");
user_pref("capability.principal.codebase.p1.id", "http://www.example.com");
user_pref("capability.principal.codebase.p1.subjectName", "");`
user_pref("signed.applets.codebase_principal_support", true);
Replace www.example.com with the domain that you want to grant the privileges to. Also add this line to your JS code before you call the preferences API:
netscape.security.PrivilegeManager.enablePrivilege('UniversalXPConnect');
A local file (something loaded from file:///) is allowed to request additional privileges. Normally you would get a prompt asking whether you want to allow access - you can "auto-accept" the prompt by adding the following lines to prefs.js in the Firefox profile:
user_pref("capability.principal.codebase.p0.granted", "UniversalXPConnect");
user_pref("capability.principal.codebase.p0.id", "file://");
user_pref("capability.principal.codebase.p0.subjectName", "");
You page can then do:
netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect");
var branch = Components.classes["#mozilla.org/preferences-service;1"]
.getService(Components.interfaces.nsIPrefBranch);
branch.setBoolPref("javascript.enabled", false);
This will definitely work if your page is a local file. Judging by the error message however, you are currently running code from about:blank. It might be that changing capability.principal.codebase.p0.id into about:blank or into moz-safe-about:blank will allow that page to get extended privileges as well but I am not sure.
However, none of this will really help if JavaScript is already disabled and you need to enable it. This can only be solved by writing an extension and adding it to the test profile. JavaScript in Firefox extensions works regardless of this setting.
That means you need Javascript to toggle enabling or disabling Javascript.
function setJavascriptPref(bool) {
prefs = Components.classes["#mozilla.org/preferences-service;1"]
.getService(Components.interfaces.nsIPrefBranch);
prefs.setBoolPref("javascript.enabled", bool);
}
The Problem
There's an item (foo.js) that rarely changes. I'd like this item to be stored in the browser's cache (using Expires header). However, when it does change, I'd like the browser to update to the newest version.
The Attempt
Foo.js is returned with a far future Expires header. It's cached on the browser and requires no round trip query to the server. Just the way I like it. Now, when it changes....
Let's assume I know that the user's version of foo.js is outdated. How can I force a fresh copy of it to be obtained? I use xhr to perform a POST to foo.js. This should, in theory, force the browser to get a newer version of foo.js.
Unfortunately, this only seems to work in Firefox. Other browsers will use their cached version of the copy, even if other POST paramters are set.
WTF
First off, is there a way to do what I'm trying to do?
Second, why is there no sensible key/value type of cache that browser's have? Why can I not simply not include in headers: "Cache: some_key, some_expiration_time" and also specify "Clear-Cache: key1, key2, key3" (the keys must be domain specific, of course). Instead, we're stuck with either expensive round-trips that ask "is content new?", or the ridiculous "guess how long it'll be before you modify something" Expires header.
Thanks
Any comments on this matter are greatly appreciated.
Edits
I realize that adding a version number to the file would solve this. However, in my case it is not possible -- the call to "foo.js" is hardcoded into a bookmarklet.
You can just add a querystring to the end of the file, the server can ignore it, but the browser can't, it must treat it as a new request:
http://www.site.com/foo.js?v=1.12345
Many people use this approach, SO uses a hash of some sort, I use the build number (so users get a new version each build). If either of these is an option, you get the benefit of long duration cache headers, but still force a fetch of a new copy when needed.
Why set your cache expiration so far in the future? If you set it to one day for instance, the only overhead that you will incur (once a day) is the browser revalidating that it is the same file. If you still have not changed it, then you will not re-download the file, the server will respond with a not-modified response.
All caches have a set of rules that
they use to determine when to serve a
representation from the cache, if it’s
available. Some of these rules are set
in the protocols (HTTP 1.0 and 1.1),
and some are set by the administrator
of the cache (either the user of the
browser cache, or the proxy
administrator).
Generally speaking, these are the most
common rules that are followed (don’t
worry if you don’t understand the
details, it will be explained below):
If the response’s headers tell the cache not to keep it, it won’t.
If the request is authenticated or secure (i.e., HTTPS), it won’t be
cached.
A cached representation is considered fresh (that is, able to be
sent to a client without checking with
the origin server) if:
* It has an expiry time or other age-controlling header set, and
is still within the fresh period, or
* If the cache has seen the representation recently, and it was
modified relatively long ago.
Fresh representations are served directly from the cache, without
checking with the origin server.
If an representation is stale, the origin server will be asked to
validate it, or tell the cache whether
the copy that it has is still good.
Under certain circumstances — for example, when it’s disconnected
from a network — a cache can serve
stale responses without checking with
the origin server.
If no validator (an ETag or
Last-Modified header) is present on a
response, and it doesn't have any
explicit freshness information, it
will usually — but not always — be
considered uncacheable.
Together, freshness and validation are
the most important ways that a cache
works with content. A fresh
representation will be available
instantly from the cache, while a
validated representation will avoid
sending the entire representation over
again if it hasn’t changed.
http://www.mnot.net/cache_docs/#BROWSER
There is an excellent suggestion made in this thread: How can I make the browser see CSS and Javascript changes?
See the accepted answer by user, "grom".
The idea is to use the "modified" time stamp from the server to note when the file has been modified, and adding a version parameter to the end of the URL, making your CSS and JS files have URLs like this: my.js?version=12345678
This makes the browser think it is a new file, and so it does not refer to the cached version.
I am using a similar method in my app. It works pretty well. Of course, this would assume you are using something like PHP to process your HTML.
Here is another link with a more simple implementation for WordPress: http://markjaquith.wordpress.com/2009/05/04/force-css-changes-to-go-live-immediately/
With these constraints I guess your only option is to use window.location.reload(true) and force the browser to fresh all the cached items.. it's not pretty
You can invalidate cache on a specific url, using Cache-Control HTML header.
On your desired URL you can run (with xhr/ajax for instance) a request with following headers :
headers: {
'Cache-Control': 'no-cache, no-store, must-revalidate, max-age=0',
Pragma: 'no-cache',
Expires: '0',
}
Your cache will be invalidated, and next GET requests will return a brand new result.
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).