Karma: Close the karma tab after tests finish

[mgol]

Currently Karma doesn't close its tab on which tests are run. For most browsers it's not a problem as there are new profiles created for each Karma run. However, Safari is an exception. If you have an option to keep tabs from the previous session turned on, it causes the Karma tab to open twice, making all tests run twice on the browser (and 3 times during the next one etc.).

I think this is a problem & Karma should just close its tab just before closing the browser.

[lazd]

This is a problem even if you have it set to not restore tabs:

Safari open with: A new window
New windows open with: Empty page
New tabs open with: Empty page

I believe it has to do with the way Safari is being closed. A normal command+Q results in a fresh session when Safari is launched, but when Safari is launched/quit by Karma, launched Safari always shows the Karma runner.

[jimthedev]

I'm having this same issue on Mavericks with Safari 7.0.2. It actually doesn't seem to happen unless I have singleRun set to true in my Karma config.

[guillaumevincent]

singleRun set to true make the tests slower
IMO Karma need to open a new tab in a new Safari, like it did with Firefox

I'm on Mavericks with Safari Version 7.0.2 too

[zedd45]

Problem still exists in Safari 7.0.3 (Mac OS X 10.9.2).

[vojtajina]

Anybody interested in looking into this?

For FF, Chrome, Opera we create always a fresh profile. However, Safari does not have anything like that (at least I don't know about it). We could remove all the Safari cache, however that would remove everything else (if the user uses Safari for regular browsing).

I think closing the tab before killing the browser is the best solution.

[eemeyer]

I'm seeing the same issue with Safari 7.0.3 (9537.75.14) on Mac OS X 10.9.2. Additionally, Safari is caching the javascript files for my ReactJS components under test (event across restarts). I had to explicitly clear my cache in order for it to pick up my changed components. I have no caching issues with Chrome. Any suggestions on how to further diagnose the caching issue?

[chevdor]

same with Safari 8.0.3 (Mac OS X 10.10.2)

[gardenvarietyse]

A small hack (emphasis on hack) for the Safari launcher that seems to work, but has definitely not been extensively tested: gardenvarietyse/karma-safari-launcher@28eb4f19737af74037cb5cf17160f9770172bbd1

Should be possible to properly hook into the event system somehow, but I'm not that fluent in Node or Karma's codebase

[shaharmor]

Any update on this?

[xhocquet]

I'd also love some info, I'm getting three Safari instances in my tests, and I'm not sure if it's related but the last Safari instance takes way more time than the other browsers:

Safari 9.0.1 (Mac OS X 10.10.5): Executed 28 of 50 SUCCESS (0 secs / 0.099 secs)
Safari 9.0.1 (Mac OS X 10.10.5): Executed 33 of 50 SUCCESS (0 secs / 0.998 secs)
Safari 9.0.1 (Mac OS X 10.10.5): Executed 50 of 50 SUCCESS (7.001 secs / 5.99 secs)
Chrome 46.0.2490 (Mac OS X 10.10.5): Executed 50 of 50 SUCCESS (0.177 secs / 0.157 secs)
Firefox 41.0.0 (Mac OS X 10.10.0): Executed 50 of 50 SUCCESS (0.266 secs / 0.246 secs)
TOTAL: 150 SUCCESS

[shaharmor]

Solution: run this on terminal: defaults write com.apple.Safari ApplePersistenceIgnoreState YES

[HowlingEverett]

That's not a wonderful solution since it means that Safari will never remember open tabs in between app launches, which is a really useful feature for normal browsing. Closing the open tab before killing the safari-launcher is a better solution.

I'll have a look and see if there's any decent way of doing this.

[HowlingEverett]

It's not a wonderful set of options, but we have pretty much two ways to programatically control Safari:

1. AppleScript (Hacky, but free-standing, the main difficulty will be identifying the instance and the tab containing the Karma runner)
2. A Safari Extension: this gives us a nice programatic API for locating tabs, selecting them, closing them, etc. But it would require the user to install the extension separately before using karma-safari-launcher. It would be possible to just distribute the extension package with the karma-safari-launcher distribution, though.

Of the two, probably the extension is the safer bet. You could spend many hours on an Applescript solution that fails in annoying and hard-to-control ways. But, I'm more of a JS guy than an Applescript guy so maybe somebody knows a reliable way of making it work :P

[HowlingEverett]

So, AppleScript may be actually a decent way to go, this _almost_ works:

tell application "Safari"
    set windowList to every tab of every window whose (URL contains "localhost:9876")

    repeat with tabList in windowList
        repeat with thistab in tabList
            close thistab
        end repeat
    end repeat
end tell

This works if I manually paste the karma runner URL into a normal, manually launched version of Safari. However, it doesn't work with the secondary instance of Safari launched by karma-safari-launcher

_EDIT_ I tell a lie. It works with either, however if there are two instances of Safari open (e.g. you have it open manually, and the launcher has opened a second instance) then it defaults to the primary/manual copy which doesn't have that tab open, and ignores the instance with Karma running in it.

Does anybody have any suggestions for selecting multiple instances of an application in AppleScript?

[HowlingEverett]

Hrm. The AppleScript 'tell' block doesn't have any way of noticing running instances unless they have different names. Honestly, since there is no such thing as a clean profile for Safari, there's not a whole lot of point launching a separate instance. It wouldn't be too difficult to patch karma-safari-launcher to do the whole thing using a node module wrapping AppleScript. This way you can launch the app if it's closed, or just attach to the running instance and open the karma runner in a new tab...and then also close the tab at the end of the session.

Of course, none of this applies to Safari on Windows, but that application is so out of date now I highly recommend that nobody runs it, lets alone tests code in it.

[HowlingEverett]

Hold the phone, we get a much lower level API using the OSAscripting API (with the nice benefit that you can use js as a scripting language for this). The other benefit is you can, for example, run grep directly and pull out the bundle identifier as a process for selecting the application.

I have to go to work now, but I think this is pretty solvable with an update to the karma-safari-launcher + OSAScript. I'll see if I can PR tonight.

[Dianna]

Glad to see someone's looking into this! Thank you

[mgol]

Another idea on how to make it work is in #20. That would not require OSAscripting and would resolve some other issues as well.

[aleksspeaker]

Hello guys,
Any updates on this issue?

[johnjbarton]

Please open this issue on karma-safari-launcher. If it is important for you I suggest you investigate and propose a fix. It just does not look like something that will be addressed here because it only affects safari and a fix is likely to be browser specific.

[mgol]

FYI, I think resolving this issue would fix this issue for Safari: https://github.com/karma-runner/karma-safari-launcher/issues/20.