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

Already on GitHub? Sign in to your account

Allow setting of browser dimensions #438

alindsay55661 opened this Issue Mar 28, 2013 · 22 comments


None yet

For some basic visual tests it would be nice to be able to specify a browser window size. This would allow for checking dimensions of various elements, viewport, etc.


psyked commented Apr 21, 2013

I get around this by setting element dimensions with javascript/jquery prior to testing, (which also works for headless PhantomJS tests) is that approach good enough?


vojtajina commented Apr 27, 2013

@psyked +1

@vojtajina vojtajina closed this Apr 27, 2013

c0bra commented Jun 4, 2013

An example of how to do this would be helpful. I've been spending most of my day trying to figure out how to test with specific custom viewport sizes and so far I haven't come up with much.


psyked commented Jun 6, 2013

For my tests, it was enough to be calling $('container'),width(800).height(600); prior to measuring and/or testing values. I'm fairly confident you can do the same at the document level if needs be, and with raw Javascript instead of jQuery.

I'm using Jasmine for the tests, so I could do this in the beforeEach section ahead of my tests, and for some slightly funky tests we also found success using the Jasmine Mock Clock to handle things which used setTimeout or required re-renders of the page before testing values.

detro commented Jun 20, 2014

This issue shouldn't be considered "closed".
The workaround suggested by @psyked might be acceptable depending on the case, but it's not a solution.

PhantomJS (and other browsers) do allow to control the window size: the issue is that you need to do it from the outer context, not from within the page/frame context.

PhantomJS has specific API for it: Karma could simple get some extra config parameters to set the page size before running the tests.
For other browsers, I guess it depends on the "launcher" implementation.

Anyhow, if I was a karma contributor, I'd consider this feature.


sylvain-hamel commented Jun 20, 2014

@detro can you expand on how that approach is not a viable solution? What is your scenario where this solution is not working?

This is what we (at my job) do and it's working fine for us:

describe('when window is resized to fit content', function() {
  beforeEach(function() {
    element.css('width', '5000px');

  it('should remove content pane preview class', function() {

We can reopen this issue if we conclude that Karma has to support this.

Thanks for your feedback

detro commented Jun 20, 2014

@sylvain-hamel I see your point and, as I said, the approach might work for specific cases.
But, aside from having to rely on jQuery to trigger an event, I think it's just not OK to pretend when it would be very easy to do the "real deal".

I was discussing earlier with the colleague that started this coversation about window resizing internally: won't be a good idea to have karma expose "special api" within the test scope, and have those wire to the outside scope to do window resizing?

This way the test could actually be about "test that at this window size that my responsive CSS/JS does what is suppose to do".

I'm sure there are plenty of other ways to circumvent the need. But if the Browsers do support such things, why not try to use them?

Dakuan commented Jul 9, 2014

"This way the test could actually be about "test that at this window size that my responsive CSS/JS does what is suppose to do".

+1 for this feature in order to achieve the above


maksimr commented Jul 9, 2014

@detro I think this tests more integration tests.
I prefer approach @psyked in most cases you can avoiding use live DOM for testing.
Also this issue more for launchers than karma itself.


detro commented Jul 9, 2014

I disagree: the launcher would have to expose the feature, but karma should provide it.

But I don't have enough bandwidth to provide a PR so, as you guys wish.

jacobq commented Sep 22, 2014

@sylvain-hamel, correct me if I'm wrong, but it seems to me that your work-around does not actually change the width of the window but rather some container element. It works for some cases, but it's really not the same as being able to drive the browser's size programmatically. I have a few components that rely on <body> width, which I believe is always linked to the size of the window, and I'd like to be able to automatically test with a live browser.


sylvain-hamel commented Sep 22, 2014

@jacobq, you are right, it wouldn't work in your case.

jacobq commented Oct 9, 2014

@vojtajina was this closed because it was deemed to be unnecessary / unhelpful or for another reason (possibly a technical constraint)? It seems like a feature that would allow more thorough testing of code used for responsive web design in a way that isn't otherwise possible. Would you consider re-opening this feature request? If you / the core team agree that it'd be a good fit I wouldn't mind putting in some effort implementing this feature.

Herriau commented Nov 11, 2014

Please consider reopening this.

+1, we wonder if it's possible to dynamically change resolution using Karma and Phantom.js, not only setting it in the config file

myoung8 commented Dec 1, 2014

As @jacobq mentioned above, this solution won't work if you need to test anything that relies on media queries (e.g. any responsive designs) since media queries rely on the dimensions of the window itself.

It appears that PhantomJS has default dimensions of 400x300 when initialized by Karma--would be great if that was customizable so that we can set Phantom's dimensions to mimic a typical desktop browser.

myoung8 commented Dec 1, 2014

I spoke too soon :)

See the docs for https://github.com/karma-runner/karma-phantomjs-launcher

It is customizable, just add this to karma.conf.js:

customLaunchers: {
  'PhantomJS_Desktop': {
    base: 'PhantomJS',
      options: {
        viewportSize: {
          width: 1228,
          height: 1000

detro commented Dec 1, 2014

Well, I guess whoever implemented it in karma-phantomjs-launcher understood why this made perfect sense.
I'm glad.

@myoung8 Thanks for mentioning karma-phantomjs-launcher! I was hoping karma would have exposed this functionality, but it makes sense to not have karma tie in too much with PhantomJS.

@myoung8 I'm not able to resize the viewport using that config. It seems to be ignored.

esr360 commented Mar 9, 2017

Config didn't work for me either, I'm still having issues with media-query dependent code due to being unable to alter the browser resolution.

squidfunk commented Jul 20, 2017 edited

For anyone who is coming here from Google and has this problem: I wrote a simple karma plugin called karma-viewport which enables testing of responsive features at ease, as long as karma runs inside an iframe (default).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment