We Keep Coding

Javascript function document.querySelectorAll works weird on Chrome

I am trying to get elements by the Chrome developer console using the function document.querySelectorAll, the point is that it does not return any element, however I see the elements on the Elements tabs.
I was wondering whether someone has faced similar issues. Shall I change some options on the browser configuration?
By the way, the Chrome version is 63 on MAC. In addition, the page I am working on has an iframe html tag, may this be the reason of the strange behavior?
This is what I get from the Developer Console
And this is what I get from the elements tabs:

There aren't any browser settings that would affect document.querySelectorAll(). It's pretty core functionality.
You mentioned an iframe, so it's likely that is the source of the confusion. When using iframes, you can't access or modify the contents of the iframe directly from the outer level. To the outer level, it's essentially a black box. This is due to sandboxing that the browser does.
The exception to this is if the iframe and the main page are on the same domain (e.g., http://example.com/page1 and http://example.com/page2).
If they are both on the same domain, then you can access it's window with contentWindow:
const iframe = document.querySelector('iframe');
iframe.contentWindow // the window for the iframe
From there, you can access its document, and run querySelectorAll() against that:
iframe.contentWindow.document.querySelectorAll('div');
That will get all of the div elements in the iframe.

Toggling iFrame Sandbox

I'm trying to figure out if it's possible to programmatically change the value of sandbox for an iFrame.
From MDN iframe:
When the embedded document has the same origin as the main page, it is
strongly discouraged to use both allow-scripts and allow-same-origin
at the same time, as that allows the embedded document to
programmatically remove the sandbox attribute. Although it is
accepted, this case is no more secure than not using the sandbox
attribute.
However, changing the attribute in the parent does not successfully trigger sandboxing as that would imply in the child.
document.getElementById('myFrame').setAttribute('sandbox', 'allow-scripts');
The page loaded in that iFrame can successfully gain access to the parent, which would not be the case if sandboxing was working. The attribute does change, but the security is flawed as it does not prevent access to the patent.
console.log(window.parent.document);
The above still works in the iFrame which had the sandbox "programmatically" enabled. This is the case in both Chrome and Firefox, which would imply either intended undocumented functionality or a poorly implemented specification.
Anyone have any ideas on what would be the appropriate expectation?

Please try this fiddle : http://jsfiddle.net/yAwxy/
It's not working when the script is runned onLoad b/c the iframe is already working.
If you try onDomready, the sandboxing is applied b/c the script didn't run yet.
If you log using this fiddle:
<iframe id="myFrame" srcdoc="<script>console.log('Executing script inside iFrame')</script>">
</iframe>
And in the script
console.log('Executing script inside page')
When the script console.log('Executing script inside page') is wrapped onLoad, the outpu is :
Executing script inside iFrame
Executing script inside page
And when wrapped onDomready :
Executing script inside page
Executing script inside iFrame
See also http://jsfiddle.net/yAwxy/1/.
So to change the rules, they must be changed OndomReady

I am running into similar issues when trying to dynamically create iframe contents in Internet Explorer inside of a sandboxed iframe. I tried doing the same thing you did with using javascript to add the sandbox attribute after the iframe was already created and content placed in the iframe (using a javascript: URI in the src= attribute) but the iframe appears to keep it's attributes that were present at the time of being loaded in the page.
Internet Explorer does appear to work differently than FireFox or Chrome when it comes to applying the sandbox attribute. Chrome and FireFox will allow the contents to be dynamically created using src=javascript:function() when the sandbox="allow-scripts" is set. IE appears to apply the unique domain from the sandbox attribute during creation and considers src=javascript:function() to be not-same-origin and will not allow the dynamic creation of the iframe contents.
I am not sure why you are trying to add the sandbox attribute programmatically, but if it is an issue of trying to just load an iframe with dynamic source you can use the srcdoc attribute as well as the sandbox attribute with the only issue being that IE does not support the srcdoc attribute.
To answer your question, I do not believe it is possible to load an iframe and its contents and then add the sandbox attribute after the fact and have the iframe behave as a sandboxed iframe.

Safari parent javascript function

Im having a strange issue only in safari browser, im calling a parent window's javascript function from within a child iframe.
Initially the iframe's src will be an external site which will redirect to my site after the work is done. The redirect page contains the following three lines of code.
This seems to work in all browsers except safari.
The only call within the iframe is
<script>
self.parent.PARENT_FUNCTION("param");
</script>
Ive tried several other ways instead of self.parent like top.PARENT_FUNCTION,etc but still the main window's location seems to change.
One thing we noticed is that while the redirect is happening within the iframe, im getting a security certificate warning, once I clieck continue, then the browsers location changes to the new redirect url instead of just the iframe's src.
any clues what could the issue be ?.

Apparently the issue is with safari browser and invalid security certificate of the site within the iframe.
It basically does a frame busting and changes the main window's url if the site within the iframe is having an invalid ceritificate.

Javascript Manipulation of DOM Within iFrame From Opened Window

My main page is from "DomainA" and I have an iFrame within that from "DomainB". The page within the iFrame has an onclick event to open a window, also from DomainB.
I'm trying to update an input field inside the iFrame from the opened window using:
window.opener.document.getElementById('foo').value = 'bar';
This works fine in FF, however in IE I get the error: SCRIPT70: Permission denied
It seems like I'm getting blocked because of the Same Origin Policy, but the page that opens the window, and the opened window are both from DomainB.
I'm using a relative URI within window.open(). Is IE determining domain from the parent of the iframe?
How can I get around this?

Turns out another developer had added the follwing line inside one of the scripts:
document.domain = 'bla.com';
This was causing that behaviour. Please disregard, thx.

How do I build an iframe with the same domain as the page in Safari/WebKit

The scene: I'm writing an embeddable widget. It takes the form of a <script> tag, which builds an iframe containing everything it needs to display. The iframe has no src, and the script writes to it with theIframe.contentWindow.document.write(). This keeps the widget contained, and keeps element ids and script from conflicting with the page on which the widget is embedded.
The trick: The widget has to be able to change its size. To do this, it sets its containing iframe's style.height. This requires access to the outer page's DOM. In Firefox and IE, this is allowed, because the iframe's document and the outer document are considered to share an origin.
The twist: In Safari, however, the two documents are considered not to share an origin. The inner document is considered to be at about:blank, while the outer document is clearly using a different protocol and "domain" (if blank can be considered the domain).
The question: How can I build an iframe programmatically whose document Safari/WebKit will consider to have the same origin as the document of the window creating it?
Edit: After further experimentation, I can't find a way to programmatically create an iframe whose location is not about:blank regardless of whether I change its contents.
If I create the frame with document.createElement(), give it a src which points to a real HTML resource on the same origin called "foo.html", and document.body.appendChild() it, Safari's console shows the element as expected in the DOM, but the contents of the page do not appear, and the document is listed in the sidebar as "about:blank".
If I include the HTML for the iframe directly in the page, the contents of foo.html appear, and "foo.html" appears in the sidebar.
If I insert the HTML using document.write(), I get the same result as with document.body.appendChild().
Both programmatic versions work in Firefox.

The best suggestion I could give is to have the iframe set to a blank page on the same server (ie blank.html) and then edit the content. A pain in the rear, I know but it's a workaround.
You could also try
iframe.contentDocument.open("replace");
iframe.contentDocument.write("<b>This is some content</b>");
iframe.contentDocument.close();
However, I'm not sure if that only works in IE. Sorry I couldn't be more helpful than that.

Aha. This seems to be a bug in WebKit. When an iframe is created programmatically, its src attribute is ignored. Instead, the frame defaults to about:blank and must be directed to a URL to point elsewhere. For example:
theIframe.contentWindow.location = theIframe.src