I've got a web form (using the ZK framework), let's say at http://www.example.com/myform
This form get's included in my main page (for example http://www.anotherexample.com) in an iframe.
Now the strange thing:
In Internet Explorer 9-11, the IFrame completely reloads whenever I unfocus a field (some field checking happens there). But this ONLY happens in IE and ONLY in the IFrame. If I load the http://www.example.com/myform directly, it works fine.
Another detail that makes the whole thing strange is: If I addtionally open a tab in the IE and load http://www.example.com/myform there, the iframe suddenly also works fine (after one reload).
Unfortunately, IE does not display any errors when reloading the iframe, so I have no clue what happens and why. Other browsers (Firefox, Chrome) work perfectly fine with the IFrame.
Any clues what might be the reason there?
In this case, the reason was P3P, as described here: https://blogs.msdn.microsoft.com/ieinternals/2013/09/17/a-quick-look-at-p3p/
In short, Internet Explorer rejects cookies from third-party contexts (different domain) in iframes, etc. This of course leads to the behavior mentioned:
Any request (including something that triggers on "focus lost") sent to the ZK backend will not have a session id (because no cookie), so ZK will trigger a complete reload.
Opening the ZK application in another tab allows it to create a cookie - which then the ZK application inside the iframe can access
The solution is to send the correct P3P header, in ZK this can be done in various ways, for example via the .zul file header directive, in a servlet filter or directly on the webserver. Having done this, the application works as expected in IE 9-11.
Related
Background / use case
I would like to automate some page interactions by pasting a script into my browser console (normally Chrome/Chromium or in my case IE11 because.. don't ask.)
Typical steps in one iteration:
(initial) Visit a page, wait until it is fully loaded.
Fill in form values automatically, trigger some buttons, submit.
Wait for new page after form submission.
Go to 'next page', wait until it is fully loaded, start over with a new set of form values.
The "Visit a page" or "Go to 'next page'" could either happen by clicking a button, or by setting document.location.href explicitly.
The "wait for ..." can take up to 30 seconds in both cases. Not for any good reason, just because.
I am aware (to my current understanding) that the js (event listeners etc) included in a page does not survive a new page load. I am specifically asking about js called form the browser's developer console.
Question
How can I register an event listener from the console for "page load complete" after setting document.location.href, or doing something equivalent?
As mentioned, in my use case I would need to do this with Internet Explorer 11. But I assume people are more familiar with the developer tools in Chromium or Firefox. Any answer that works in one of these browsers is welcome, just mention which browser you tried this with.
Limitations
I do not control the web application where I want to do this, I only control my browser. It also does not look like the developers of said application would be likely to respond to feature requests or wishes.
Perhaps someone will suggest to do this with an iframe. I am not sure this will work. If it does, this would be a different question.
Perhaps someone will suggest some kind of browser simulator tool to use instead of the console. Unfortunately I need/want to make this work on Internet Explorer in a corporate Windows environment with limited privileges. Alternative tools can be mentioned, but there is a reason why I focus on browser console.
I am currently creating a new version of a website that uses a third party service that can only be accessed through an iframe. This service exclusively works on Internet Explorer (not on Edge) in compatibility mode (and with certain security options set), while the new website is developed with more modern browsers in mind (mainly Chrome).
Is there any way to insert an iframe into the page, and make the iframe load its content with IE's engine even though the page containing it has been loaded in Chrome?
I'm not talking about the "user agent" field in the request header (as discussed in this question), I'm talking about rendering the response with a different browser's engine.
No, there isn't.
Not even if the computer has Internet Explorer installed.
iframes dont have a support for browser option selection. so this requirement cant be fulfilled. there is one plugin called ietab but its only for development purpose, which runes ie in chrome browser.
I've been working on a React JS application with rackt/react-router and testing has recently uncovered an odd behavior specific to IE9.
Context:
We have our F5 set up to perform a protocol redirect (302) so that if someone attempts to navigate to http://react.site.root/#/virtual.page it will redirect them to https://react.site.root/#/virtual.page. Since this is a single page app the redirect is really occurring on http://react.site.root/. This redirect happens as a result of a Keep-Alive request.
Problem:
In IE9 when this protocol redirect occurs the user ends up at https://react.site.root/#/default.route regardless of the virtual page they were attempting to hit. This issue is not seen in later versions of IE, Chrome (desktop or Android), iPhone 5s or 6 (didn't have actual devices to test others). Interestingly enough it also occurs when using any iPhone version in BrowserStack.
My Research:
I have also searched using stackoverflow and Google and the only semi-related issue I found is that IE9 caches redirects, but from what I understand that only applies to 301 redirects and since the protocol redirect path does not include the virtual page or any routing data in the cookies that doesn't seem to fit. Nevertheless I found a test for this that required deleting browser history and running a tab under InPrivate Browsing which indicated this was not the issue. I have also recorded the request and redirect response in Fiddler for both working browsers and IE9 and see nothing suspect.
It seems as though IE9 is treating the redirected page as a new page in the sense that maybe the original javascript context is being destroyed on the redirect, which would explain why react is using the default route. Unfortunately I don't know how to test that theory or move forward with this issue in general. Any help is greatly appreciated.
I found the answer. In short, IE9 and some older browsers forget about the fragment portion of the originally requested URL and will only use fragments present in the redirect response. Since the browser strips the fragment out before making the original request to the server it can't be present in the redirect location.
See the following for more info:
URL Fragment and 302 redirects
http://blogs.msdn.com/b/ieinternals/archive/2011/05/17/url-fragments-and-redirects-anchor-hash-missing.aspx
put this at the top of your <head>:
<script>
window.location.hash = window.location.hash
</script>
Problem solved
I am working with the YouTube Data API v3. Google recommends loading the libs using:
<script src="https://apis.google.com/js/client.js?onload=googleApiClientReady">
It works fine but when I load the script like this into a modal window in Firefox (it's got to be this way. I can't control the way my widget is called by Sitecore) it fails with:
Error: Permission denied for https://accounts.google.com to call method ModalContentWindow.postMessage
It comes from within internal callbacks that Google's client.js calls when loaded even if I omit the ?onload part.
Works fine loaded into a standalone tab. IE and Chrome do fine either way.
Is there a good way to make it work in FF modal window? (I am running 27.0.1 if it matters)
UPDATE: I worked around it by calling YouTube Data API HTTP endpoints directly. I am still wondering though what's up with that postMessage() thingy in FF's modal window and whether it's known to the authors of Google's client.js.
The main problem is that Firefox has policy for capability.policy.default.Window.postMessage.get but it doesn't have policy capability.policy.default.ModalContentWindow.postMessage.get.
There is two way to solve this issue.
add pref for Firefox pref("capability.policy.default.ModalContentWindow.postMessage.get", "allAccess");
instead of loading the script into a modal window directly put it inside iframe. iframe would have class Window.
BTW I faced this issue in FF28. In FF31 everything works fine.
I have a web page that links to another web application, which unfortunately only completely functions in IE, so, when viewing the original page with another browser (like Chrome or Safari) I display a warning that the application won't operate fully operate unless opened in IE.
Of course, some savvy users of Firefox have the IE tabs extension and have configured it such that the problematic web application always opens in an IE tab. These users would prefer it if my intrusive warning weren't shown for them as it is not necessary.
So, is there a way that my web page can detect that the URL will open in an IE tab? I presume it would require the extension to expose this information somehow as Firefox does not generally allow javascript access to settings for security reasons.
well I am not sure how FF's IE tab works but I assume they share cookies set a cookie when it is IE and check whether it exists and do not show the warning. This will only remove the warning after first usage if my assumption about cookies is correct.
Second is more hacky, use css :visited puseudo styles to detect whether your user has ever downloaded the XPI of firefox tabs.