First time poster. Currently trying to work on a project but I am having an issue with iframes. I'm making an extension for Chrome, and part of its functionality right now is to be fetching any shapes/borders on a page. Unfortunately, that also includes ones within iframes. I'm currently stuck because I cannot get around security policies from Cross-Domain sources.
I was wondering, however, if it is possible to create a function that displays what the Chrome console does when I hit "inspect element" on a page... I tried to make a console function called "save" that would automatically download a file of anything output to the log, but the output for the iframe's HTML is blank except for its tag...
When I am inspecting an element on the page, I can see the contents of that iframe just fine. Is there anyway to just get the actual text from Inspect Element and store that? I know this may be silly, but I genuinely have no idea. I am pretty new to JavaScript. I just need to match up script tags for shapes for part of the extension's functionality.
I'm assuming that this is going to end up being impossible, but I figured I'd ask. I'm also assuming that this inspect element functionality is something that only the browser can work with. But hey, maybe there's a way. Thanks for any help.
Related
I've done some looking around and couldn't find any solution to this problem.
I'm creating a Chrome extension, with a manifest that points to the opening file home-times.html. This works, though I want to redirect it internally to the other page home-welcome.html inside the extension so it loads another page INSIDE the extension.
I've read a lot of questions that refer to changing the current tab's page, though that's not what I am after.
Tests
By using the following code:
test
Opens a new tab, with the extensions page that I am trying to access in that new tab.
If I got you right, you want to change your popup innerHTML, in this case I suggest using jQuery, to change original file to the result you want.
If you just want to open new tab, with your home-welcome.html, you can do this, in your popup.js :
window.open('home-welcome.html','_blank')
If none of this is what you are looking for, can you please provide an example, I will try to help.
So I have a working manifest.json that runs a content script on chrome://extensions and the content script that does this:
"document.getElementById("joodangkbfjnajiiifokapkpmhfnpleo").remove();"
I have the flag for running extensions on chrome:// urls enabled and I know the manifest.json works because if I make my content script do something like change the background, on chrome://extension, it does.
I don't know how to easily explain this, but when I run the script mentioned above in the chrome console after I reset the page, it says that there isn't any element by that ID. That is until I inspect element on the extensions, then it isn't null. It's almost as if the element doesn't exist until I inspect element on it. It doesn't make sense to me, however, because I know it obviously exists due to me being able to see it. I hope I explained this well, anyone know why this happens and how I can make my script work?
I'm using CasperJS to scrape a website. The page source has a <noscript> tag, and therefore is not showing the page I need to scrape, because it claims I don't have JavaScript enabled.
javascriptEnabled is true by default in CasperJS, but I added it to my initialization anyway, to no avail.
Any work arounds to fix this issue? It might also be an issue with PhantomJS...
Ok this issue has been fixed -- I did the following, if anyone has any questions. The HTML was rendered by the JavaScript, which took a long time to load, so open it like you would normally in a browser, and find an element that only appears when the javascript loads -- note doing view source doesn't work you have to inspect element (you get current DOM).
I then did:
casper.waitForSelector('.SOME_CLASS', function() {
this.echo(this.getHTML('.SOME_CLASS'));
this.echo(this.getElementInfo('.SOME_CLASS').text);
});
This allows the page to stop and load the javascript.
The client's website has product listings. The prices for the product are pulled dynamically in through an iFrame at the bottom of the page. There is Javascript on the page that automatically resizes this iFrame to the correct height based upon how big the iFrame content is, once it's loaded.
The client is reporting that when printing the page, they cannot see anything from the iFrame where the prices should be - apparently it is not printing in IE, just the main page itself.
I am on a Mac and so can't test in IE, so I'm having a hard time experimenting with this.
Can anyone clarify the expected behaviour in this situation? Is it possible to get IE to print both page and included iFrames by default, and if so, how would I go about doing this? I can only find examples for printing a specific frame from a parent window.
Thanks!
The expected behaviour should be what you're experiencing in other browsers. If the page is printed, the iframe should be printed along with it. It would be difficult to imagine that everyone else got it wrong and IE got it correct in this instance.
Below is a bit of speculation on what the issue might be, but without knowing more/seeing code it's difficult to know the specifics:
This issue could be due to some css that you may have on your page. I've read of similar iframe printing issues where the visibility was set to hidden initially resulting in the iframe not printing correctly. To get around this specific case the user had to set the width and height to 0px. Without knowing more about your site, I can not correctly predict that this is happening.
Another issue may by your dynamic resizing based on the contents of the iframe. A simple test would be to comment that section out and set a generic width and height on the iframe to see if the printing issue still occurs. Perhaps those dynamic styles are not being carried over to the print stylesheet and are not getting applied (therefore not appearing at all).
As a quick suggestion, look into css media types:
print
Intended for paged material and for documents viewed on screen in
print preview mode. Please consult the section on paged media for
information about formatting issues that are specific to paged media.
Helpful link: Print Specification
This was an interesting point, so I did a test using IE8 (on a server, not locally).
I printed in IE8 a web page that included an iframe of something that I built. And it printed some of the contents the first time (the other contents showed up black). The second time I printed, the iframe contents were all black.
However, in my example, the contents in the iframe are changing constantly (images and text that fade in and out) and the css background behind it is black.
This test has the contents of the iFrame on a different host server than the contents of the main page. But to my knowledge, there is a cross-domain policy file working here.
Cross-domain policy issues were my first guess, but it's entirely possible there is some issue with how internet explorer renders the screenshot when it sends it to the printer.
If you are using Javascript, then why not try window.print() function along with print media CSS.
I can't explain why IE isn't working, but maybe you can fix the problem by adding this part of code into the parent page, in order to force each iframe to be refresh :
$(document).ready(function() {
if($.browser.msie) {//Only for IE
$('iframe').each(function() {
$(this).attr('src', $(this).attr('src'));
});
}
});
To get the browser, i use this method.
And i don't use contentDocument.location.reload(true); method to be sure the iframe to be refresh. See SO topic.
Try this Plugin it will solved your problem
http://projects.erikzaadi.com/jQueryPlugins/jQuery.printElement/
This is a very urgent problem and I'd be forever indebted to anyone who can lend some insight.
I'm going to be deploying a widget (called the "ISM") to a third-party site. That site uses the document.domain JavaScript property to relax cross-domain restrictions (e.g., setting document.domain in "a.example.com" and "b.example.com" to both "example.com" so they can access each other's DOMs).
This causes problems with my script in Internet Explorer due to the way that I construct an <iframe> that is used to display my widget's HTML content. In Internet Explorer, using document.domain on a page, and then creating an <iframe> with JavaScript, will cause you to be immediately "locked out" of the <iframe> - i.e., you can create it, but it's not created in the correct document.domain, so you're not able to access its DOM due to security restrictions. This isn't a problem in any other browser.
To see what I'm talking about, load this page in IE:
http://troy.onespot.com/static/3263/stage1.html
You should see a JavaScript error: "Access is denied."
To get around this, I'm setting the dynamically created <iframe>'s "src" attribute to load a static HTML file that's hosted in the same domain (different subdomain), and setting its document.domain property to the appropriate value:
http://troy.onespot.com/static/3263/stage2.html
That gets around the security issue, and lets me write the document I originally wanted to write to the <iframe>:
http://troy.onespot.com/static/3263/stage3.html
With that document in place, my widget does some polling to our server to get some HTML content that I want to insert into another <iframe>, which will be visible to visitors of the parent page. I've roughly simulated that here (using static content, not actually contacting our server):
http://troy.onespot.com/static/3263/stage4.html
Here comes the problem. When I get that HTML content and insert it into the second <iframe>, I now face an unusual issue with a broken "Back" button. This happens in Firefox 3.0 and all version of IE (possibly other browsers), though it does not happen in some browsers I've tested (Firefox 3.5, Safari, Chrome). See this page:
http://troy.onespot.com/static/3263/stage5.html
If you click the "Google" link, all seems fine. But, when navigating back to the previous page (that has the latter test script), another JavaScript error is introduced: "Permission denied." This does not terminate the script, and does not appear to have any ill effects, other than the fact that I assume it's connected to the broken "Back" button functionality, which is a very big problem - the one I'm desperately trying to solve. I'm at a loss to debug this error since its call stack starts and stops in the jQuery script.
You can also encounter this error - with more serious symptoms - by going to the last link above (stage5.html - clear your browser cache first). Click the "Stage 5 (Again)" link, then, after that page has loaded, click the "Back" button.
The "Back" button is completely broken! You can't go anywhere except to another URL.
This is the problem that I need to solve as soon as possible. Any insights or help would be extremely appreciated!
I can't deviate from this method too much, so outside-the-box suggestions are definitely welcome, but I may not be able to use them due to the constraints of the widget's specifications. I would prefer to understand why the "Back" button is breaking and how to fix it, along with the "Permission denied" error related to jQuery.
It's really hard to try out fixes for this because of the multiple domains. One thing I've heard is that IE treats a blank src or "about:blank" as a different domain, but it treats 'javascript:""' as the same domain. Have you experimented with changing stage one to set the iframe src to things like:
iframe.src = 'javascript:""'
Or:
iframe.src = 'javascript:parent.getFrameHTML()'
Part of the problem seems to be that IE (at least IE 7) adds two entries to the history named "Domain" when I click on the "Stage 5 Again" link. When you use the little drop-down arrow next to the Back button you'll see the history of pages allowing you to step back more than one step. I see the previous two entries are listed as "Domain" and clicking either of those brings me to the same page. The fourth spot (after Current Page, Domain, Domain) is the correct "ISM Back Button" link to the original stage5.html page.
So the problem isn't exactly that the back button doesn't work, but just that the entries in the history are added and so the back button takes you to the wrong place. I don't have an answer as to why those "Domain" entries are being added to the history, but hopefully this helps point you in a useful direction.
Good luck!