squidfunk / karma-viewport

A Karma plugin for testing responsive features and layout

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Debug context middleware not being registered

lsglick opened this issue · comments

Description

I can't figure out how to get the debug context middleware to be automatically registered.

This line returns false for me (I think config.context as well as client are undefined in my environment):

if (config.context === "#context" && client.useIframe) {
.

I can workaround this by manually adding beforeMiddleware: ['viewport'] to my karma.conf.js.

Expected behavior

Middleware to automatically be initialized (or clear instructions on how to enable it).

Actual behavior

Middleware setup is skipped.

Steps to reproduce the bug

  1. Follow setup instructions on README.
  2. Run tests in debug context
  3. Notice the debug.html doesn't have any iframe

Package versions

  • karma-viewport: 0.4.1

System information

  • OS: Ubuntu
  • Browser: Chrome

Can you provide your karma config?

Here's most of the config. At one point I'd explicitly set client.useIframe and viewport.context but it didn't seem to make a difference.

config.set({

  basePath: '..',

  plugins: [
    'karma-mocha',
    'karma-webpack',
    'karma-chrome-launcher',
    'karma-phantomjs-launcher',
    'karma-sinon-chai',
    'karma-mocha-reporter',
    'karma-junit-reporter',
    'karma-sourcemap-loader',
    'karma-viewport'
  ],

  // Hack to workaround https://github.com/squidfunk/karma-viewport/issues/29.
  beforeMiddleware: [
      'viewport',
  ],

  frameworks: ['mocha', 'sinon-chai', 'viewport'],

  files: [
    'test/index.js'
  ],

  exclude: [
  ],

  preprocessors: {
    'test/index.js': ['webpack']
  },

  webpack: webpackTestConfig,

  webpackMiddleware: {
    progress: true,
    stats: true,
    debug: true,
    noInfo: false,
    silent: false
  },

  client: {
    mocha: {
      reporter: 'HTML', 
      timeout: 30000
    }
  },

  mochaReporter: {
    showDiff: true
  },

  junitReporter: {
    outputDir: 'reports/karma'
  },

  reporters: ['mocha'],

  colors: true,

  logLevel: config.LOG_INFO,

  autoWatch: false,

  browsers: ['Chrome'],

  // karma-viewport
  viewport: {
    breakpoints: [
      {
        name: 'mobile',
        size: {
          width: 414,
          height: 736
        }
      },
      {
        name: 'tablet',
        size: {
          width: 768,
          height: 1024
        }
      }
    ]
  },

  singleRun: false,

  concurrency: Infinity,
  
  browserNoActivityTimeout: 120000,
  
  });

I'm sorry for not answering for so long. I'm currently on vacation and will look into it in the beginning of September.

I have the same problem. Debugging the commit that broke this functionality yields the following results:

if (config.selector === "#context" && client.useIframe) {

  • config is the global karma config object, not the framework specific config as the code assumes. karma's config setting 'context' is not specified. It should be config.viewport.context.
  • client throws a reference error. It's supposed to be config.client.useIframe.

As stated you can get around that by using:

  config.set({
    // ...
    beforeMiddleware: ['viewport'],
  })

Thanks for providing this plugin. It's super useful for testing CSS media selectors.

Are you both sure that you are using the most recent version (0.4.1)? The code snippet both of you posted relate to a version below 0.4.0. There was indeed a bug in the comment you referenced. The current check negates the client.useIframe property, which is correct and should make your code work:

if (config.context === "#context" && !client.useIframe)

Furthermore note that in 0.4.0 the name of the property config.viewport.selector was changed to config.viewport.context.

I'm sure. This is the current master and it's also what my local package shows. See the framework method, deciding whether to push the middleware or not:

https://github.com/squidfunk/karma-viewport/blob/0.4.1/src/index.js#L62

The commit I referenced shows the point in time when the behaviour broke, not the most recent code. My previous comments and results also relate to the current version (0.4.1) of the plugin, sorry for the confusion.

Ok, sorry, my fault, got the wrong line. This was indeed a copy and paste error. Will provide a fix asap.

A fix is provided in #30 which removes the check. The beforeMiddleware is now always registered which is even better and more extendable.

Released as part of 0.4.2. Please re-open if the problem persists.