Elements in iframe not loading (found) when using chrome headless - javascript

I am writing a script that has to enter an iframe in order to interact with certain inputs. In this case, the inputs are credit card related.
In Chrome head mode, the script runs perfectly fine. In Chrome headless mode, I always get this error: "Content of the iframe in which the test is currently operating did not load.".
I haven't had this problem in other scripts, so I'm assuming it's because these fields are credit card (payment) related, but I'm not finding anything online that confirm my suspisions.
Can anyone confirm or provide insight and is there a workaround (without changing elements)?
Thank you,

Is the iframe content ready at this moment? You can check it by making a screenshot of the whole page via the await t.takeScreenshot() command or the takeOnFails option. If the iframe content on the screenshot looks fine and the cause of the error is unclear, try one of the following workarounds:
add some waiting timeouts: await t.wait(timeout)
implement a ClientFunction that will check if the iframe content is ready. Here is an example of this approach: https://stackoverflow.com/a/10444444

Related

Getting the contents of Chrome's console with JavaScript

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.

How to solve "Permission denied to access property 'alert'"?

There is a webpage i am making a greasmonkey script for. This page has several iframes. I have found out that they are the problem, however i do not know how to solve the issue.
At first my script creates a small div box with the button. By pressing a button script analyzes webpage contents and calls alert on certain conditions.
Javascript console in Firefox already shouts to me that access was denied for document because my script is using document.getElementByID to find the top document's body, where the div box is being appended to.
This is easily avoidable problem as then script fails and gets stuck in iframes, yet it still continues on the main page as it does give the access to document.
The problem araises when i try to use alert in my function. Seems like iframes take over my script and kills it with the Permission denied to access property 'alert'.
How do i tell browser/script or whatever, that i only want my script to run on main document and i do not want to be bothered by iframes?I installed NO-script addon, allowed the primary domain and blocked the secondary domain (that loads inside iframes) and all the alert messages go normal. But, i can't ask my users to install noscript enable/disable specific domains and my script should be working fine. I need to find solution which would work with all the iframes enabled.
Hope it didn't sound confusing.
Thank you for any help.
RE:
How do i tell browser/script or whatever, that i only want my script to run on main document and i do not want to be bothered by iframes?I installed NO-script addon, allowed the primary domain and blocked the secondary domain (that loads inside iframes) and all the alert messages go normal.
First, adjust your include and exclude directives to ignore the iframes as much as possible. EG:
// #include http://example.com/normal/*
// #include http://example.com/extra/*
// #exclude http://example.com/extra/in_iframe/*
Next, add these 2 lines as the first lines of code after the Metadata Block:
if (window.top != window.self) //-- Don't run on frames or iframes
return;
That will stop the GM script from running on iframes.

Page behaviour modifying google chrome extension?

I really want to make google mail by default bottom posting, in other words, I want the cursor in the textarea in a reply message to move automatically to the bottom.
Is this possible with google chrome extensions?
Have you maybe any other suggestions?
Problems I'm facing:
Run the extension script when gmail is fully loaded
The target textarea is in it's own iframe, is it possible to access it?
Yes, you may use the Content Scripts feature of a Chrome extension in order to manipulate the
page a user is browsing. Your content script code will run in the context of the web page the user is browsing, and it may interact with the host page almost without limit.
Manipulating Gmail might be a bit trickier than most other pages, due to its dynamic nature. Consider using the jQuery .live() method to make it easy bind to the elements you want to manipulate.
With regard to iframes, you just have to turn on the "all_frames" option in your manifest, which "controls whether the content script runs in all frames of the matching page, or only the top frame."
(I know this question is a bit stale, but I thought maybe you'd still appreciate an answer.)
I hope that helps.

Notifying iFrame page from Firefox extension?

I'm writing a Firefox extension and need to notify an iFrame page of certain events. The iFrame page is contained within a sidebar created by the extension, and this iFrame page is controlled by me.
When I load the iFrame page, the extension code needs to send a notification and trigger something to happen within the iFrame page.
To accomplish this, I'm creating an event from the extension Javascript and firing the event, which the iFrame page is listening to.
Unfortunately, when invoking document.createEvent(), this error pops up (copied, with the quotes, straight out of Firebug):
Operation is not supported" code: "9
Any clues on the error, or suggestions on how to trigger something in an iFrame page from the extension Javascript?
Firebug helps debug web pages. From your description it appears that the problem happens in your extension, so set up the profile according to the documentation and look in the Error Console.
Other than that, remote debugging requires seeing more of your code :)
That error is NS_ERROR_DOM_NOT_SUPPORTED_ERR. Are you using the right document (the content one, not the XUL window)? Although, I'm not convinced that that would error out either (in fact, I think it should work).
This is an example of code that works for me:
var eventName = "my-event";
var event = document.createEvent('Events');
event.initEvent(eventName, true, true);
document.getElementById('my_event_listener').dispatchEvent(event)

Document.domain and <iframe>s breaks the "Back" button in Internet Explorer

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!

Categories