I want to be able to change the language used by browser windows (and reload the page, without restarting the application). I'm currently using CefSharp 69.
My first attempt was to call Cef.Shutdown() and then Cef.Initialize() again with a different Locale in the settings (since this appears to be the only way to set that value). (Of course, closing all the existing browsers first and creating them again afterwards.) However it appears that calling Initialize after Shutdown crashes with an unmanaged memory exception, so that's a no-go. (This seems like a bug.)
My second attempt was to set the browser.BrowserSettings.AcceptLanguageList after creating the browser but before navigating it. While this does appear to update the value sent in the Accept-Language header as expected, it does absolutely nothing to the JS navigator.languages and navigator.language properties on the resulting page, which remain reporting the old language. (This seems like another bug.)
My third attempt was to set a RequestContext and then call SetPreference for intl.accept_languages. This does set JS navigator.languages and navigator.language, but doesn't send any Accept-Language header. (This seems like another bug.)
So currently I've managed to cobble together something that seems to work as expected by doing both the second and third thing, but this seems entirely ridiculous.
I subsequently tried updating to CefSharp 91 (the latest currently available). This behaves mostly the same, except that setting intl.accept_languages appears to do both things now, while setting AcceptLanguageList still only affects the request header and not JS.
Related
I want to be certain that the omniture calls for document.write()'s are nullified/cleared from the DOM for each new call.
Criteria:
I want to see what gets written to the DOM with a Adobe Omniture call(s.t() call) for example
I want to make sure that the DOM writes are cleared/nullified out before adding each new call
How to prove the DOM value is nullified/cleared.
I assume you are talking about this part of the on-page code:
/************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/
var s_code=s.t();if(s_code)document.write(s_code)//--></script>
Adobe Analytics (Omniture) tracking makes its request to the collection server by creating an image object. Modern browsers make the request when you set the imageObject.src attribute with the URL. The reason document.write() is used is to accommodate if the request is not made from simply setting a value to imageObject.src.
Basically, the AA code checks if the imageObject.src successfully loaded the returned image. If so, s.t() returns an empty string. If not, s.t() returns a full img tag, which gets added to DOM from the document.write().
This document.write() fallback is meant to accommodate older browsers. And by "older" I mean IE4 old. If you do not care about tracking browsers that old (hint: nobody does), you can just cut all of the "trigger" code down to the single s.t() call (no need to even assign to s_code).
So to answer your question, nothing is actually document written to the DOM unless you are on an ancient browser. But in the case that you are on an ancient browser.. no, there is no code that removes previous stuff appended. Which brings me to...
..What are you really asking? IOW, why are you trying to find out / make certain that it is removed? I suspect what you may really be asking is something along the lines of wanting to make sure previously set AA variables do not get popped on subsequent requests. Which is a fair thing to ask, but that doesn't really have anything to do with the request itself. But you will need to clarify that point.
I can see this site.com/assets/css/screen.css?954d46d92760d5bf200649149cf28ab453c16e2bwhat is this random alpha numeric vales question mark ? i don't think it's taking some value to use or what is it about ?
edit : also on refreshing page the alpha-numeric value is same.
It is for preventing the browser from caching the CSS. When a CSS is requested by some browsers, specifically Internet Explorer, the browser will have a local copy of the CSS.
When a request is given to a server as:
site.com/assets/css/screen.css?skdjhfk
site.com/assets/css/screen.css?5sd4f65
site.com/assets/css/screen.css?w4rtwgf
site.com/assets/css/screen.css?helloWd
The server at site.com sees only:
site.com/assets/css/screen.css
And gives the latest version. But when the HTML page is requesting the browser to fetch the CSS as: site.com/assets/css/screen.css, for the first time, it fetches from the site.com server. There are many possibilities that the content might be changed in the meantime when the next request is sent. So programmers generally add a ?and-some-random-text, which is called Query String. This will force the browser to get a new copy from the server.
Some more detailed explanation:
It is a well known problem that IE caches too much of html, even when
giving a Cache-Control: no-cache or Last-Modified header to
everypage.
This behaiviour is really troubling when working with querystrings to
get dynamic information, as IE considers it to be the same page
(i.e.: http://example.com/?id=10) and serves the cached version.
I've solved it adding either a random number or a timestring to the
querystring (as others have done) like this
http://example.com/?id=10&t=2009-08-06_13:12:56 that I just ignore
serverside.
Is there a better option? Is there another, cleaner way to acomplish
this? I'm aware that POST isn't cached, but it is semanticaly
correct to use GET here.
Reference: Random Querystring to avoid IE caching
I am trying to block URLs with a certain keyword in a JavaFX webview. So far, I have tried using webEngine.locationProperty().addListener() to listen for a change in state. While this is successful in blocking the URL, it unfortunately leaves the locationProperty set to the value that I am trying to block. This causes problems for links that use references on the page.
Two solutions I have tried for setting locationProperty back to its correct value:
Calling webEngine.load(). This causes the page to refresh and the user loses work.
Calling webEngine.getHistory().go(0). As it says in the documentation, this does nothing.
I can think of two general ways to solve this problem:
Find a place earlier in the chain of properties than locationProperty that gets changed to listen.
Figure out a way to change locationProperty back to its correct value without reloading the page. (I think this might be possible through reflection which I've been trying to avoid up to this point.)
Do either of these solutions sound reasonable and if so what is the best way to implement them?
(Sorry this is rather a vague question. My attempts to be clearer [and indeed to be more code-oriented] have failed...) :-/
//
I've installed the Firebug for Drupal module, and I notice that it shows I'm apparently loading the same eight node objects on every page for no apparent reason. These are all of the same content type (the site uses many other content types).
It seems they are actually all the nodes of this one content type, excepting those produced as dummy content by the developer module.
I've flushed the cache multiple times.
Is there a way to work out where these nodes are being loaded from???
Install devel.module, add ddebug_backtrace(); inside the node_load() function. Reload the site. Now you should see 8 browsable backtraces which will tell you which function calls node_load().
At a guess, you probably have a block (from a view or module) which is querying those nodes on every request.
http://heydon.com.au/node/1044 has a short writeup on this behaviour. If so, the fix is to remove that block from the regions which are rendered, or configure it to only be displayed (and therefore rendered) on pages where you want it to be run.
Drupal caching should prevent those queries being run for anonymous users (depending on the caching and block settings, of course).
I've had this happen with 3rd party modules that were repeatedly calling node_load() needlessly. What I would suggest is for you to disable all 3rd party modules, retry you node loads and re-enable them one by one until you catch the misbehaving module.
Good-luck!
Whenever we make changes to the CSS, it generally takes 24 hours to reflect those changes on my site. I have tried clearing the server cache and browser cache but it doesn't help too. Is there any other way to make the CSS changes reflect immediately after updation?
it happens in all the browsers... when i check it in the browser , i can access my css file with two paths eg : i store my css in folder named "Cssfolder" and my css name is say 135.css
So when i access the folder paths, Cssfolder/135.css & cssfolder/135.css, one of the path shows me latest css whereas other one shows me old css.Notice the "c" is captital in one path whereas small in other path.
Thanks.
I've found this to be a pretty common problem in a lot of my projects. I would suggest two things...
If it's just an app that you are working on you can use the CSS Cachebuster during development.
Following the idea behind the Cachebuster I have found that often adding the timestamp of the CSS file as a query string off of the CSS link will help in telling the browser that the file is different... something like... whatever.css?12212009035543
You might want to use a monitoring tool, like Live Http Headers for Firefox, to see the requests and responses to and from the server. This usually solves a lot of problems for me. Take a look at the "Expire" headers and conditional requests (like: "If-modified-since"). This said, take a look at server and client local times and timezones - it might be that they differ significantly and conditional GET requests "seem to be" handled correctly, because of future or otherwise mangled timestamps.
You can force to load the current css directly from the server with appending a random unique value to the url, like http://example.com/Cssfolder/135.css?983274928374 and http://example.com/cssfolder/134.css?08973249827. There's no way that this would ever get cached unless you use the same random value twice.
This way you learn where to look further for the solution to your problem: At the server, the ISP/a proxy or your browser.
You really need to see whether this is server side or client side. If the server is still serving the old CSS then clearly you've got no chance on the client side.
I've occasionally seen times where I've had to show the CSS in the browser, and then next time I've been to the real page, it's used that new CSS. Usually just hitting refresh does it.
Do you have any web caches like Akamai involved anywhere?
If you try to go to the CSS page from a computer which has never seen the old version, which version does it show?
EDIT: Changed answer to reflect edits in question.
I have been dealing with this issue in the past, and ended up writing a httpmodule to deal with it.
It's pretty simple, it just finds all script/css links in head tag (they now need to have runat=server) and appends the assembly version number to the link, in the same way as Tim K describes. This way im sure my clients always fetches the newest css/scripts when my app is updated in production, and never have to deal with this issue again.
Maybe Internet Service Provider cache, as in this case?
I was perplexed by this issue then someone said Ctrl+F5. Worked for me :)
When I am developing and I need to be sure that I am seeing changes as I work, I stick the css in the page ie
<style type="text/css">
/* your css */
</style>
Or you could constantly change the name of the css file itself, not very useful in a production environment, but perhaps okay while developing.
I know it doesn't solve the problem, but for developing it is okay.