I'm running Selenium in singleWindow mode and IE8.
If i start IE8 manually the IE8 mode is set, but when i launch it with Selenium, the mode set is IE7 using the compatibility mode.
Anyone knows why the compatibility mode is not the IE8 view when launching the browser with Selenium?
Or, how can i disable totally the compatibility mode in IE and force it to use always the IE8 view?
I've given the question a +1 because it's a very good question -- it's not obvious how to do this, and if you need to test both modes, then it is a necessary thing to do.
You could get the site to serve <meta http-equiv="X-UA-Compatible" content="IE=7" /> within the page when running the tests. This should force the output mode.
Obviously, that's not ideal, because it means changing your code to produce the meta tag on demand. I'd normally consider it a bad thing if you're having to change the main codebase in to add code for the specific use of your test suite, but in this case I can't see any other solution.
Given that we've decided to go down this path, you could write your code to accept a specified argument in the URL that triggers the meta tag to be served. The IE7 tests could then be written to send that URL argument.
By the way, it's worth pointing out that IE8's IE7-compatibility mode is not 100% identical to IE7; it has its own quirks and bugs which are distinct from those of a real IE7 browser. For the most part it should be fine, but it's worth being aware of this if you're expecting your tests to confirm that the site works in IE7. See this blog post for more info
I have some workarond solution for this, I use it regularly:
In internet explorer goto:
1. Tools / Compatibility view settings.
2. At the Add website input textbox add your website url.
Hope that helps, best regards,
Peter Nadasi (HUN)
Related
I am customizing iNotes (Notes web mail client), adding some features using javascript that require ajax calls to external sources. In doing so I have found Internet Explorer won't perform CORS (cross-origin) requests. Errors are either access denied or some other security errors depending on how it's called. Chrome and FF and Safari all work.
I have found what I believe to be the culprit, iNotes adds a meta-tag to emulate IE9.
<META http-equiv="X-UA-Compatible" content="IE=EmulateIE9" />
For CORS requests, IE9 does not support XMLHttpRequest, rather you must use XDomainRequest, which was only supported in IE8 and IE9. Since it's emulating IE9, the XMLHttpRequest (or jQuery .ajax calls for that matter) don't work.
I have not been able to find any way to remove that meta tag, I did a search on the mail file and there are no matches for IE=EmulateIE9 that I could find. And I'm sure if I did remove it, I would break something in iNotes.
I didn't want to load jQuery, but may do so for this script and include the moonscript plugin which uses XDR for ie8 and ie9 browsers. If iNotes is ever updated, it will still work.
Anyone else run into this problem and find a better solution?
Lothar Mueller pointed me in the right direction.
Domino 9.0.1 Fix Pack 5 adds a Forms9s.nsf which allows you to get rid of "Quirks Mode" for IE backwards compatibility. After installing the FP, the new forms9s.nsf file is installed, then you update the notes.ini with
iNotes_WA_DefaultFormsFile=iNotes/Forms9s.nsf
iNotes_WA_FormsFiles=iNotes/Forms9s.nsf
and it eliminates the emulation tag for IE. I still have to test my iNotes customization apps, but this gives an option for running some IE features that didn't work before such as Ajax requests from iNotesExt_9.nsf, etc.
When I am trying to upload a file using ieframe in IE9<, am getting the error in developer tools:
HTML1113: Document mode restart from IE9 Standards to Quirks
Hence the upload status is not displayed. I tried using meta tag <meta http-equiv="X-UA-Compatible" content="IE=8"> but it's still not working.
Can any one throw some light on it.
According the IE11 console error reference:
"HTML1113: Document mode restart from [mode] to [mode]
The webpage requires a different document mode than the browser was
currently set to.
This message can occur when the user browses from another page, so it can be out of the developer's control."
Given your description, it sounds like your child frame is embedded within a larger document. If that's the case, verify that the document modes of both document are consistent. If one requires standards mode, the other should be using it as well.
For best results, use the HTML5 doctype (<!DOCTYPE html>) for all documents; this will trigger standards mode (or edge mode, as it's now called) in each version of IE. If you're not able to do this, then you may wish to try opening the framed document in a new window, rather than embedding it on a parent document.
Hope this helps...
-- Lance
I have been using TinyMCE WYSIWYG in CMSMS(CMS Made simple), its working in all other browsers like FF,IE7,8,Google Chrome & Safari but its not working in IE9,
When i try to update any data and then save it, its look good with successfully save message but actually its not at all saved my changes.
i'm very much tired by goggling for this issue but get no success at all.:(
i have seen that this is the issue which also occur in JOOMLA 1.5X. in joomla if we are suppose try to write anything in Editor then all save,apply and cancel button not been worked.
Please help me out from this unusual error.
i appreciate your efforts.
Thanks.
Mark Dexter from Joomla! CMS Development says:
This is a perfect example of the problems we run into when trying to
support a version like 1.5 for such a long period of time. On the one
hand, we want to stay up with current versions of 3p software. On the
other hand, we want to maintain backward compatibility. These two
goals become difficult if not impossible over such a long time period
(> 3 years). Mark
As a workaround you could use JCE, which is using a far newer version of TinyMCE and its based on it.
http://extensions.joomla.org/extensions/edition/editors/88
Secondly you could try manually updating TinyMCE to 3.4.x, which fixes the problem download and extract
http://github.com/downloads/tinymce/tinymce/tinymce_3.4.4.zip into /plugins/editors/tinymce
/jscripts/tiny_mce
Good Luck
Just logout from your Admin Console once and then login again..But before logging in,make sure,you change the URL in your browser..
If its http://yourdomain.com, then make it http://www.yourdomain.com and then login..
That should work :)
Another permanent fix for this is;
or you can use more advanced Editors like com_jce
Just use
<meta http-equiv="X-UA-Compatible" content="IE=8" >
In your header tag and IE9 should emulate IE8.
If that still doesn't work try to get it to render in IE7 compatibility. This is not something I would struggle with I would just turn on compatibility till the next release of TinyMCE:
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" >
One of our products uses a Javascript Rich text editor, which has the ability to accept pasted HTML/Word and clean it up so the html is XHtml valid and presentable.
This has been working fine for a few years, but recently we've been having complaints about pasting; from users with IE8.
It turns out that regardless of setting the group policy setting for allowing pasting, or prompt for pasting; if IE8 mode is enabled, it won't paste.
If you turn on compatibility mode, it works correctly, but we'd like to have a solution that works across the board.
Has anyone had this issue or similar ?
Unfortunately, we deal with a lot of corporate/local goverment entities that don't have the flexibility to change their browser/policies without submission through strict change-request red-tape :(
Thanks for any insight!
If you aren't worried about formatted text then try the clipBoardData object. It's not ideal but its about the only thing that works other than running in compatibility mode via the web developer tools.
Not a solution, but could you use the <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" /> meta-tag to force compatibility-mode for IE8 users?
I think some intranet group policy settings may override that and it's a sticking plaster rather than a solution, but it may get you by while you find a proper fix.
It looks like IE7 doesn't reload the latest version of my stylesheet each time I upload a new version on the server.
This is annoying as I am debugging my .css file to make it work on IE...
Tried to empty the browser cache but still not working.
Thanks for your help.
Ctrl-F5 - forcible way to reload in IE
Include your version number in the file name. myfile_v1234.css
When testing, every time you do an update you can just wite "stylesheet.css?r=98123"
As long as the query string is different, it'll be downloaded again.
If you need, you can use javascript to append Math.random(), to get the random number. Not required on production though, when updates would be stable.
2 Questions:
Does IE eventually load with the newer stylesheet?
How are you saving the changes to the server (SSH, Web Interface, etc.)?
I ask because I ran into an issue with a web-based file management system a while back where one browser would show the CSS just fine, the other wouldn't, and we noticed the issue of which browser played nicely depended on which browser we used to upload the CSS.
The reason turned out to be that IE gave the CSS file a different MIME type than Firefox. If you continue to notice the issue even when you've cleared the cache, check the MIME type of the file using Firefox by going to Tools > Page Info.
Also, if it is simply a caching issue, consider turning caching off in IE. I believe this should be an Advanced Option under Internet Options.
Also, you may want to try creating a special developer environment for IE (if it comes down to it.) Perhaps have another machine with IE7 and no caching and any other features turned off (A kiosk mode, perhaps), and then previewing the page on that machine.
Thanks to you all!
I did manage to solve my problem with the "stupid" Ctrl+F5, and by changing the Internet Parameters of Windows to reload content every new visit.