I'm trying to implement DoubleClick on a client's site and having a heck of a time. Part of the problem is that when things don't work, things just don't work. Nothing is logged to the console, no alert boxes appear, no uncaught exceptions are thrown, nothing. Nevertheless, through experimentation, I've managed to get things to the point where iframe tags are being inserted in the positions where the ads should be on the page; it just seems that the iframes aren't having src attributes given to them, so they're just appearing as blank areas on the page.
It would be wonderful if someone had an answer on how to solve that exact problem, but failing that, I'd settle for a way to coax the DoubleClick script into just making a bit more noise when something goes awry. When I look at the minified/obfuscated script being loaded from Google's servers, it does look like there's plain English strings woven in there representing various error cases, so I presume there's a way to make it display those strings to me…
From my understanding the iframes will not have src attributes... I think the reason they are used is as a form of sandboxing so that ads cannot interfere with the parent page in any way... an iframe allows different css, scripts etc without it conflicting.
If your ad units on your page are appearing blank then it is most probably because there are no line items that match... make sure you are using the build tags tool inside DFP... that hasn't failed me yet... also check out the debugging console, this should display any errors that you have with your page.
Related
While developing a full-fledged website for a client, who is slightly obsessed with Google tools and suggestions, I've come across the following issue:
No matter what I do, I cannot achieve a perfect score for the homepage of the site. All other pages are 100/100 on both mobile and desktop, but the landing page gets 91 and 97 respectively - as you can see in the attached pictures.
I have tried all relevant steps I could find, including correctly structuring the HTML code and asynchronously loading everything else, plus lazy-loading the images.
A dummy representation of the code would be this:
html head, metatags etc
inline blocks of css (to "fix" the render-blocking issues)
the html content, in correct order with above-the-fold first
deferred js load
My question is, what am I missing? What else can I do to achieve the perfect score?
For future reference and anyone facing the same problem:
I've solved this issue by reducing the filesize for my homepage PHP file. This was nowhere in the guidelines or the responses around the web, but it was the thing that bumped me up to 100/100.
In my particular instance, I removed every last bit of unnecessary CSS I had included. That alone reduced the size and removed the error.
I consider the issue erroneous however, and will proceed to report this to Google - as "prioritize visible content" has nothing to do with "reduce your file size".
I have a content script running inside the Gmail UI and I am injecting some new HTML at different points. This is all working, but to keep the code clean I wanted to insert pre-defined HTML markup into certain parts of the page in a single function call.
This all seems feasible using chrome.extension.getURL(), but when I was testing this, it looks like chrome.extension is undefined! I was unable to find anywhere in the documentation that says this shouldn't be defined and several places where it says it should.
I am using chrome Version 39.0.2171.95 (64-bit)
Here is what the chrome object looks like in the javascript console:
First off, anyone know why chrome.extension might be undefined? Secondly, is there another (perhaps better) way to do this? I'd rather not just programmatically inject a large amount HTML into the page in code using jQuery, etc. in the content script, but can resort to this if there is no other way.
If you're testing this in the console, you must be aware of the concept of the Isolated World. When you add a content script, it has a separate JavaScript context for itself that is isolated from the page.
At the top of the Console tab of Dev Tools, you'll see <top frame> in a dropdown. This is a dropdown that selects JS context it is executing in. It will list frames inside the document and all extensions that have content scripts injected.
The chrome object you show in the screenshot corresponds to what the webpage normally sees. If you switch context, you'll see a different picture:
In any case, if you are really executing chrome.extension.getURL() in the content script - it will be well defined.
Now, if you injected a <script> tag in the page and tried it in that code - it would fail again, since the code will be in the page context. See this question for this situation.
Finally, most of the Chrome API will not be exposed to content scripts for security reasons. If an API is undefined when it shouldn't be, you may need a background page to do the job for you.
I would like to remove some hosting imposed google ads on my phpbb board.
Currently I accomplish this by deleting via javascript all the banners divs when the page is loaded.
But unfortunately in that way advertisements are quickly displayed before disappearing.
Now I am thinking about a different (neater) approach to my problem:
maybe I might write some javascript code which interferes with the one injected by google thus generating the inability to show those annoying divs...
Any idea?
EDIT
I can't edit html and css, I am just allowed to insert any html/javascript/css code in a separate "widget". This is for testing purposes and I have the admin permission to try ...
My current code follows
<script type="text/javascript">
window.onload = function(){
document.getElementById('ad').getElementsByTagName('div')[0].outerHTML='';
document.getElementById('ad2').outerHTML='';
document.getElementById('footer').outerHTML='';
document.getElementById('ad3').getElementsByTagName('a')[1].outerHTML='';
};
</script>
Any error-inducing code will almost certainly interfere with things required by phpBB as well as the ads. Generally the ad code is written to be stand-alone, so it doesn't need any external help (eg. scripts in the <head> of the document).
Maybe you could target their parent elements with CSS and just apply display:none or something? That would likely be a better solution.
First off, you should be sure you're allowed to remove these ads, doing so without permission could get you into trouble.
Assuming by this point you are allowed to:
Throwing an error will most likely crash your own script which tends to be a terrible idea.
You could:
Try to look for the script tag with the URL and remove it
Make css rules to hide the div's before they are even displayed, then removing any code generated by the ads.
Re-write your javascript so it doens't conflict with the other script.
Ok, so somewhere on my site is a Javascript file that after a few seconds, injects an iframe to an unknown site into the page. What it injects fails miserably and the HTML is a bit messed up, but it's concerning because the iframe src has changed since the last time I checked.
Code Injected:
<divstyle="height:2px;width:111px;">
<iframe style="height:2px;width:111px;" src="http://nleskoettf.com/index.php?tp=001e4bb7b4d7333d"></iframe>
</divstyle="height:2px;width:111px;">
For an up-close and personal glance: http://caseconsultant.com is where it injects (see bottom of page). Don't worry, the URL in the iframe src is dead (downforeveryone.com/nleskoettf.com), it's not even a working website which is the really confusing part.
Anyone know how I can track back the injected HTML to the source?
Anyone able to do that?
You may use a tool like Noscript to block domains for scripting and localize the script that injected the iframe.
Then you will see that the iframe will not be present when you block twitter.com
There is a function inside http://caseconsultant.com/wp-content/plugins/contact-form-7/scripts.js?ver=2.3.1 (see the last line) that loads some JSON-data from twitter and creates the iframe(maybe using data from the twitter-response, may be a reason for the changing url).
This also may be interesting to you: Is this dangerous Javascript? (It's the same function)
I'm not sure if this is malware, maybe there is only a bug inside the function that creates invalid HTML/URL
But the function has nothing to do with a contact-form, and also isn't a part of the original scripts.js(you'll find it here: http://downloads.wordpress.org/plugin/contact-form-7.2.3.1.zip ), so I'm afraid the site has been hacked(except you put the function there on your own).
So what you can do:
Read this (removing the function will not be sufficient, as long as you didn't remove the vulnerability)
Check the Server-Logs, script.js has been modified on 11 Nov 2011 19:57:00 GMT , has there been something suspicious-looking? If not you may assume there is no server-side vulnerability(but server-logs can be modified too), ....
Change your FTP-Password
Scan your PC for malware
I'd recommend using Chrome's Developer Tools to figure this out. If you load your site in Chrome, you can then open the tools by hitting the wrench button, then Tools -> Developer Tools (Or Ctrl+Shift+I).
From there, you can use the Resources tab to see everything thats being loaded for that page, or the Scripts tab to focus on just javascript. For this problem, neither of those seem that useful, so I recommend a different method: breaking on DOM changes. Take a look in the Elements tab, right click on the <body> tag and choose Break on subtree modifications. Then, refresh the page (might need to refresh twice, Chrome bugged out for me on the first time).
You should arrive at a call to jQuery.append in the Scripts window (if not, hit F10 until you are, sometimes Chrome picks up on more or less modifications on load), and if you look at the a variable under Local in the Scope Variables sub-window, you'll see that this is trying to insert the offending div/iframe.
Now you can step through the javascript using the buttons at the top-right, or F10 and F11. If you hit F10 a few times ('Step Over'), you'll end up in the offending script, referred to by Chrome as '(program)' (means its been dynamically loaded). This has been obfuscated, so its a bit hard to read/understand, but you can use the console window to run things from the script.
For instance, the jsn function is being used to translate obfuscated text. You can use this to see all of the different strings it is using, for instance on this line:
jsg = jsn('Ch') + jsp(jsb).substring(0, jsa) + '.com/' + jsAJ($);
That constructs the url for the iframe.
This means we've identified the offending script for sure, but the fact that this is identified as '(program)' by Chrome means it has been loaded dynamically into memory to be run. This means the actual script part is most likely compressed and further obfuscated somewhere in your other script files. If you look through those script files in the Resources file, you should be able to find a line or lines that don't fit in, that look very obfuscated/compressed, and are perhaps inside of an inline function call, IE:
(function() { ... } )();
They may also look somewhat similar to the script file inside the '(program)' view. It can also help to search for things that would be hard to compress/optimize further, such as the obfuscated strings. I searched for one of those strings, haDWDosestnsdlDjfqcq, and found it at the bottom of scripts.js. Delete that line and your site should be fine!
I recently had this happen, iframe injections into the javascript files (and others!). First thing I did was a grep -n for the url on my entire server to find every instance of the injection. Just one line and fairly simple to remove. Then came the matter of tracking it down.
It turns out it was a rogue apache module that had been planted due to a vulnerability. In my case it was mod_aclr.so
Go through your /usr/lib/httpd/modules/ or /usr/lib64/httpd/modules/ directory and compare your list to the list of real apache modules here: http://httpd.apache.org/docs/2.2/mod/
If you have some modules that don't appear on that list, vi them to see what they contain, or simply do a google search to see if they are affiliated with actual modules. In my case, mod_aclr.so returned about 10 pages of Russian commentary, so I quarantined it and will be watching to see what happens now.
Here's a good writeup on the subject: http://blog.unmaskparasites.com/2012/09/10/malicious-apache-module-injects-iframes/
as obviously the css related to the page being injected is not loaded by Chromium. However, it is working well in IE8/O 10.x/FF3.6x.
Hence begs the question - my stupidity in html coding, Chromium bug or jquery bug? that is what I could think of.
this is the page in question, eliminated all non-essential js http://logistik-experte.gmxhome.de/test.html, navigate to resume and see the difference. It is basically driving me nuts as missing the point somewhere and hence any sound advice/help would be highly appreciated.
cheers
I agree with Buggabill: works for me in Chrome 5. (At least on the server; there may be issues with loading files from a local filesystem.)
However there are problems with your approach. By having page content loaded by script only, you have made your page inaccessible to non-JavaScript users, which includes all search engines. Also you can't use the back button and the pages are unbookmarkable, un-open-in-new-tab-able, and so on.
Basically you've reinvented all the problems of <frameset>, the reasons why no-one uses frames any more. You shouldn't really deploy this kind of solution until you are familiar with the ways accessibility and usability can be served. At the very least, you need to point the navigation links to the real pages containing their content. Then consider allowing hash-based navigation, so the dynamically-loaded pages have a unique URL which can be navigated between, and which will re-load the selected page at load time when the URL is first entered.
Also if you are loading content into the page you should take care to load only the content you want, for example using load('portfolio.html #somewrapperdiv'). Otherwise you are inserting the complete HTML, including <!DOCTYPE> and <head> and all that, which clearly makes no sense.
To be honest, as it currently is, I don't see the point of the dynamic loading. You have spent a bunch of time implementing an unusual navigation scheme with many disadvantages over simple separate navigable pages, but no obvious advantage.