Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(Docs) Karma fails to capture Internet Explorer 10 on 64-bit Windows #429

Closed
bitwiseman opened this issue Mar 26, 2013 · 13 comments
Closed

Comments

@bitwiseman
Copy link
Contributor

Tested using Internet Explorer 10 on Windows 8 64-bit.

This is not a bug in Karma but a limitation of IE and node.js that we need to document.

Repro:

  1. Clean install windows 8
  2. Install node.js 0.8.22
  3. npm install karma - (Testacular)
  4. npm install
  5. Change karma.conf.js to run IE in single-run mode
  6. testacular start karma.conf.js

Expected:
karma to launch and capture IE, run tests, exit and close IE

Actual:
karma launches IE three times and believes IE has exited each time.

Notes:
I believe this is specific to IE 10 64-bit Windows (7 or 8). If anyone else can repro, that would be great.

@bitwiseman
Copy link
Contributor Author

Workaround/Fix:

  1. Set IE_BIN to "C:\Program Files\Internet Explorer\iexplore.exe".
  2. Add http://localhost to the "Intranet" Zone (or possibly any zone that has "Protected Mode" turned off)

Explanation:

  1. Karma uses %PROGRAMFILES% to locate Internet Explorer. On 32bit OS, this behaves as expected. On a 64-bit Windows with IE 9 (or earlier) this also works - the 32-bit version of IE runs on the 64-bit OS. On 64-bit windows with IE 10+, launching 32-bit IE now causes IE to re-launch a 64-bit process with the same parameters, and exit the 32-bit process with exit code 1. We must instead tell Karma to launch the 64-bit version of IE from the start.
  2. Unsure why this is needed, but it does seem to matter. My current theory is that Protected Mode prevents IE from being a child of another process.

@vojtajina
Copy link
Contributor

Yep, this is happening, because the process exits (as it probably starts a child one).

We should set correct binary for specific version of Windows, created an issue for it.

Besides, I think we might support this kind of scenario where the launcher forks a child process and exits immediately. Even though, not sure if it's possible, as the child process parent pid will be 0.... Any thoughts ?

@bitwiseman
Copy link
Contributor Author

Yeah, the advantage of spawn is that the browser closes when the parent closes. We might have an option to ignore the exit code and just watch for timeout in communication.

@vojtajina
Copy link
Contributor

Karma uses child_process.spawn to launch browsers.

@stevebroshar
Copy link

I see that IE is not exiting at the end of a karma test run. There is a new iexplorer.exe process running after each karma run. I think this is the same issue being discussed in this thread (even though the title is about capture -- which seems like a different thing to me).

Anyway, I made the two changes listed in the workaround/fix above. But, it made no difference. IE still does not exit.

I don't know what to ask. I'm just sharing that I can repro the problem and that the workaround does not work for me.

I am running win7-64 and IE10.

@necolas
Copy link

necolas commented May 30, 2013

I'm having the same problem with IE 8 on XP.

Latest stable release of Karma and Node.js. Whether Karma is configured for single-run or not made no difference. I also couldn't get the workaround to resolve the issue.

@tonte-pouncil
Copy link

Well I am having the same capturing problem; but I am using VMWare Fusion to launch IE from my mac. I added the http://localhost into my intranet zone for IE, and turned protected mode off in IE. The one good thing that came from doing this is now Karma only launches IE once instead of 3 or more times.

Setting the IE_BIN variable doesn't help me because IE is not on my local file system; but rather on my virtual machine. I wonder how might I solve this problem? Any ideas?

@bitwiseman
Copy link
Contributor Author

I'm closing this, and opening it as a linked issue in the IE launcher module.

@gantaa
Copy link

gantaa commented Aug 20, 2013

The following steps fixed the capture problem for me on Windows 7 - 64 bit - IE 10:

  1. Set IE_BIN to C:\Program Files\Internet Explorer\iexplore.exe
  2. Turn off run IE in protected mode in Internet Options > Security

I did NOT have to add localhost to my local intranet zones sites, but I'm sure it wouldn't hurt.

This does NOT solve the problem (@stevebroshar commented above) of extra IE 32 bit processes being spawned, even though we are pointing karma to launch IE 64 bit directly. This is a big problem because with every CI build there is a new process taking up CPU and memory.

@georgeflorentine
Copy link

I also ran into this problem:

  • karma v0.10.2
  • Windows Server 2008R2, 64 bit
  • IE 9

I've set IE_BIN to C:\Program Files\Internet Explorer\iexplore.exe, added http://localhost to the local Intranet zone and have turned off run IE in protected mode in Internet Options > Security

3 versions of IE started, loads the initial runner.html page but Karma thinks IE isn't running.

Any other suggested workarounds? Would sure be nice to be able to use Karma to test IE in my environment. BTW, Chrome and phantomJS work ok in my environment.

@bitwiseman
Copy link
Contributor Author

On Windows Server 2008R2, 64 bit you should set IE_BIN to C:\Program Files (x86)\Internet Explorer\iexplore.exe.

@georgeflorentine
Copy link

Liam, thx for the quick reply. Actually, I misspoke in my previous post. Looks like the VMWare image that we're using is actually 32 bit, so there's only a 32 bit IE on it. So I'm already running 32 bit IE and seeing the problem I described in my previous post.

@bitwiseman
Copy link
Contributor Author

Please file an issue in the IE launcher project with accurate repro steps.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants