Allow inserting source files in the HEAD / custom context.html #488

vojtajina · 2013-04-11T06:50:10Z

Based on #430

Let's allow custom context.html and debug.html.

Add two config options:

contextFile (default __dirname + '../static/context.html')
debugContextFile (default __dirname + '../static/debug.html')

The text was updated successfully, but these errors were encountered:

redaemn · 2013-04-11T11:21:38Z

I was thinking about a more minimalistic approach; what about having something like this inside the config file:

headFiles = [
    'test/ieshiv.js',
    'test/helpers/*.js'
];

this would let you include files into the <head>.

IMHO, this would be simpler to use than the contextFile approach because the user wouldn't have to define a complete (and correct) context.html file that could be complex to do because it would have to contain correct calls to __karma__ object and other special tags (like %MAPPINGS%).

What do you think @vojtajina?

dignifiedquire · 2013-04-11T11:50:32Z

I like the idea from @redaemn. We could use a simple templating language and allow multiple entry points into the files, e.g. head and body.

filaraujo · 2013-04-11T19:31:42Z

Would love to see this feature

redaemn · 2013-04-11T20:39:09Z

@vojtajina While studying the code (it's huge, by the way...) I thought: are you sure that including the ieshiv.js file inside the <head> of context.html will solve my problem in #430??

context.html is loaded inside an <iframe>, are you sure that the ieshiv.js shouldn't be loaded inside the <head> of the parent window to work?!? (i.e. client.html file if I'm not wrong...)

Just don't want to implement something that will not solve my problem... :P

redaemn · 2013-04-11T22:09:57Z

After examining the code, I changed my mind: instead of creating a new headFiles configuration option I think it could be better to add an additional value to the included property of the files configuration.

The following code would include the ieshiv.js file into the <head>:

files = [
  { pattern: 'test/ieshiv.js', included: 'head' }
];

included property (instead of being a boolean) could accept this values:

'head' - includes the file into the <head>;
'body' - includes the file into the <body>;
false - the file is not included;
default value is 'body'

vojtajina · 2013-04-12T21:17:12Z

@redaemn Can you try to hack the context.html to include your ieshiv.js in the head to confirm that it would solve the problem ?

Now... two questions, would really appreciate feedback from everybody on this, because I don't know ;-)

What are other use cases for including a file in head ?
What are the use cases for having a custom context file ?

Another option would be have a config option registerCustomElementsOnFuckingIE = ['tab', 'pane']; that would inject proper code, either to context.html head, or even to the parent frame (there's problem if you need to register them inside head, because this file is only loaded once you starting Karma).

pkozlowski-opensource · 2013-04-13T12:07:08Z

@vojtajina - I can't think of any other use-case apart from @(*&#^$@ IE8 but I think it would be still more flexible to allow people load they own files instead of just enumerating DOM elements to be created. I'm saying this since a project will probably alrready have some kind of ieshiv.js (to be conditionally loaded in a browser) where those elements are created.

If those elements are to be enumerated in Karma's config it would mean that the list of custom tags needs to be maintained in 2 places. Not a big deal but still...

filaraujo · 2013-04-13T12:33:25Z

Not everyone follows the load scripts at body bottom paradigm, so having this flexibility is very useful. At work we tend to load vendor and core scripts at head and page specific scripts at body bottom.

I would think a body top injection point instead would satisfy the ieshiv need as well as allowing any situation.

redaemn · 2013-04-13T15:39:10Z

@vojtajina Bad news: I edited the context.html inside the global node_modules/ dir adding the ieshiv.js to the <head> but it seems that it DIDN'T solve the problem... :( the file was executed for sure (I put a debugger; statement inside it)
I also tried to put it inside the client.html file with no luck; is that what you meant when you said "hack the context.html", right?

I'm beginning to think that maybe I'm doing something wrong, @pkozlowski-opensource could you please try to debug the tests and:

confirm that they don't work for you either? In my case this line https://github.com/redaemn/bootstrap/blob/ie8-compatibility/src/accordion/test/accordionSpec.js#L135 is the one that fails with "TypeError: 'customElement' is not defined" exception;
confirm that the document.createElement('xxx') statements that are executed are in fact correct? Is something missing?
anything else that I could be doing wrong?!?

vojtajina · 2013-04-13T18:04:47Z

@redaemn are you saying that you put the ieshiv.js into context.html head and into client.html head and it still does not work ?

That would mean, we are back on page one and I have no idea why it fails...

redaemn · 2013-04-13T19:44:39Z

@vojtajina yes... that's why I'm hoping that I did something wrong from the start and maybe the problem isn't there at all!!

pkozlowski-opensource · 2013-04-13T19:49:17Z

@redaemn I'm desperately trying to finish a book about AngularJS so don't have much cycles left till the end of this month but if you could create a clean repo with a minimal directive and minimal Karma config this would help a lot. Just to have a really minimal scenario.

vojtajina · 2013-04-13T20:14:25Z

I'm gonna try the ng-directive-testing to get it running on IE8.

On Sat, Apr 13, 2013 at 12:49 PM, Pawel Kozlowski
notifications@github.comwrote:

@redaemn https://github.com/redaemn I'm desperately trying to finish a
book about AngularJS so don't have much cycles left till the end of this
month but if you could create a clean repo with a minimal directive and
minimal Karma config this would help a lot. Just to have a really minimal
scenario.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/488#issuecomment-16339525
.

redaemn · 2013-04-14T19:09:54Z

@pkozlowski-opensource that's exactly the same idea I had, we should start from a minimal example and try to understand what's going on.

I created this repo https://github.com/redaemn/karma-test, directive and test are based on those in ui.bootstrap.accordion module that are failing, they have the same structure.

In Chrome the test is green, in #&(%$@ IE8 it fails on line https://github.com/redaemn/karma-test/blob/master/test.js#L16 with the exception "Unexpected call to method or access property" (a different line and different exception than the ui.bootstrap.accordion... -.-' )

I also tried setting the included property for ieshiv.js to false and including it in the head of context.html or client.html or debug.html, no luck with neither of them.

I'm out of ideas!!

vojtajina · 2013-04-15T21:41:43Z

Ok, I started my Windows VM. Disabled sound, so that I can't hear the Windows login sound which already makes me sick. Note, I only have IE9 in IE8 mode (but it looks like the issue is there as well).

1/ the document.createElement('tabs'); DOES NOT have to be in HEAD.

2/ the element, where you are adding the custom elements into, HAS TO BE already appended to the document.

Here's the ng-directive-testing example working on IE8:
https://github.com/vojtajina/ng-directive-testing/tree/ie8

vojtajina · 2013-04-15T21:42:01Z

Closing the issue, as I don't think we need this feature.

redaemn · 2013-04-16T19:24:51Z

Sound is always off on my Winzoz VM, I really hate that login sound!!! Anyway, I tried your solution and it worked like a charm!! :D Thank you very much @vojtajina

pkozlowski-opensource · 2013-04-16T19:27:44Z

@vojtajina Vojta, thnx so much for looking into it... After reading your comments it makes sense... in a wired IE logic...

If I remember correctly attaching those DOM nodes to a document will slow down tests, right? As a browser will have to render them, calculate positioning etc. Or am I talking rubbish?

vojtajina · 2013-04-19T00:55:26Z

@pkozlowski-opensource you are correct, it's better to append to DOM only when necesary. You can do if (IE) append...

guilhermeaiolfi · 2013-07-25T11:21:29Z

Hi,

I'm coming from Testem and I'm missing the "custom context.html" feature. I think it gives the flexibility that everyone needs. Testem only asks you to insert a Testem.js in your "custom.html" to make it work. Maybe it would be cool to have a script like that one that would configure and run all that needs to be configured in the custom.html file to make things work.

The good thing about all of this is that it gives power to users that need and won't complicate the life of people that don't need it.

I would ask you to reconsider custom context.html and debug.html. Thanks.

vojtajina · 2013-07-29T09:41:50Z

@guilhermeaiolfi I'm not against a configurable context.html and debug.html.

All the karma code is already encapsulate, so you only need a one line parent.karma.setupContext(), check out https://github.com/karma-runner/karma/blob/master/static/context.html

What exactly are you missing ?

guilhermeaiolfi · 2013-07-29T11:35:11Z

What I'm missing is how to tell karma where my custom context.html file is. Or do I have to edit this file in node_modules/karma/static? Because that's not a good idea since it's not going to be checkout with my project files and my changes can be lost when installing/updating karma in the future.

vojtajina · 2013-07-30T03:56:38Z

@guilhermeaiolfi that's a valid point, we need to support that.

You are correct, changing karma/static/*.html is not a good solution. Btw, why do you need to put the scripts in the head ? So far I've only seen we need that for CSS files...

filaraujo · 2013-07-30T11:24:10Z

@vojtajina It would be nice to have the flexibility to have scripts in the head. I work with legacy systems that are mandated by asset load order, and it has proven troublesome to integrate karma with that structure. Also that would allow fixtures to be created in the head as well, another issue that I have come across.

jcc8 · 2013-08-05T06:55:43Z

Bounty added here if anyone wants to add to it: https://www.catincan.com/bounty/allow-inserting-source-files-head-custom-context-html-issue-488-karma-runner-karma-github

Crowdfund issue & get feature merged into main branch to collect.

franleplant · 2013-09-27T15:46:12Z

Is there any existing way to use a custom context.html?
Im trying to run tests over a site, and its particularly important to test over that specific site, the only solution seems to be changing the context.html to mySite.html.

patkujawa-wf · 2014-05-01T00:51:42Z

Similar to @franleplant and @guilhermeaiolfi, we have a single-page app that we'd like to run specs in the context of and it's too complicated to inject as a "fixture" (from what I know). So I would also like to be able to specify a custom context.html. It would be great it karma then injected what it needs into that page, rather than the other way around.

caitp · 2014-05-01T01:01:02Z

Why do you need to run specs inside of the context of the app? sounds like you're wanting to run integration tests, and karma might not be the best matchup for that (keep in mind this opinion may be based on outdated knowledge of karma). Have you considered using selenium for that sort of thing?

patkujawa-wf · 2014-05-01T01:04:40Z

@caitp Yeah, I get that a lot :). Yes, we've considered selenium, and may end up going that route, but right now we have these (integration) specs written in client-side JS and thought karma could be the tool we use for launching in browserstack/saucelabs and aggregating results. But the specs all rely on running within the specific app page.

@vojtajina, Is it out of the scope of karma to be a runner/aggregator for integration/functional tests (potentially using selenium, but not necessarily)? Is there another tool in that space?

Here are two examples of what needs to be injected on a page to get mocha or jasmine2 to run specs on the page - in both cases, it isn't much, but running on the page is essential.

elkwood · 2014-07-23T21:49:26Z

I am running into an issue with this that is preventing the rest of my tests from running. I'm attempting to build a webapp with Polymer which some of it's polyfills require being placed in the HEAD of the document.
I've tried even appending polymer to the head to no avail - it still catches that the dom has loaded.

WARN: 'platform.js is not the first script on the page. See http://www.polymer-project.org/docs/start/platform.html#setup for details.'

{pattern: 'src/main/app/bower_components/**/*.{js,map}', included: false, served: true},

var script = document.createElement('script');
    script.src = '/base/src/main/app/bower_components/platform/platform.js';
    document.getElementsByTagName('head')[0].appendChild(script);

I'd be fine with being able to use a custom context.html or allow the files attribute to allow placing the file in the HEAD.

All the tutorials I've found around Karma and Polymer don't seem to solve this problem for me so if anyone has an idea for this to work I'd be interested to hear your thoughts.

maxwellpeterson-wf · 2014-09-15T21:33:42Z

Would love to have this functionality.

obenjiro · 2015-03-23T12:13:34Z

Added support to add custom context.html / debug.html - in "Support for custom context and/or debug html files" #1360

Unlike other pull request this one is little bit cleaner and doesn't break existing unit tests

UnsungHero97 · 2015-09-15T00:50:29Z

any update on when this change will be ready to use? I'd like to give this a try. I tried adding in the changes from the PR, but I'm running into problems; it seems like other places need to add in the extra parameter

obenjiro · 2015-09-15T09:14:04Z

Sorry, my bad. To busy to finish the job. I will try to make appropriate pull request asap

UnsungHero97 · 2015-10-08T18:11:01Z

@AiBoy did you get a free moment to make that pull request?

T-vK · 2015-10-19T15:06:38Z

Another good point for custom context.html files is that ExtJs 6 for example wants <html manifest=""> instead of just <html>. It's also a lot of work to change the config of Karma every time you add a new script to your index.html and you can't really use internal script in your index.html file because you couldn't tell Karma how to get it for the context.html. In my opinion Karma should definitely inject into a copy of the index.html.
...and not being able to set the DOCTYPE may be another thing that could cause problems.

I'm really looking forward to this being implemented.

rosenfeld · 2016-02-10T19:57:40Z

I believe there are many reasons why allowing custom HTML would be desirable. It gives other projects flexibility to do basically any kind of experimentation with Karma without having to fork the project.

In our specific case, we use oojspec to run unit and integration tests with a single runner. Most integration test runners out there are pretty slow, like Capybara, Selenium or anything using a real browser, headless like phantomjs or not.

OOJSpec doesn't enforce the way people should write code. If someone wants to be able to register events on DOM selectors which are never unregistered because it's not needed in the application, they shouldn't change the way they write their code just to satisfy their test runner limitations. So, one is free to register those events once in a beforeAll block and then run a set of tests, which may depend or not on previous tests (they are always run in the specified order by specification) which allows some integration scenarios to be tested more quickly than it would be if the tests had to be written in an independent way and also gives developers more flexibility on how they write code.

For this to work, OOJSpec has to run each set of tests, grouped in an specification file, in a separate iframe. OOJSpec currently uses sprockets to create such structure in a similar way adopted by other gems like Konacha and others. It would be awesome to be able to use Karma infra-structure to run a custom HTML runner created to be compatible with Karma API so that it reports the tests run correctly to the client console. It should be doable once we have the ability to specify how the HTML should be written. My plan is to integrate OOJSpec to webpack and test with Karma and stop using sprockets. Another advantage of running the tests in separate iframes is that you are able to test whether all required dependencies were correctly declared since only the dependencies for that test file are loaded in the isolated iframe.

dignifiedquire · 2016-03-03T12:27:10Z

Done in #1825

vojtajina closed this as completed Apr 15, 2013

redaemn mentioned this issue Apr 16, 2013

feat(): IE 8 Compatibility angular-ui/bootstrap#249

Closed

6 tasks

vojtajina reopened this Jul 30, 2013

vicb mentioned this issue Apr 28, 2014

chore(pubspec): Replace shadow_dom with web_components dart-archive/angular.dart#972

Closed

AlbertoElias mentioned this issue Sep 1, 2014

Now inits following the spec Financial-Times/o-tabs#7

Merged

krasimir mentioned this issue Jan 2, 2015

Support custom context file #1277

Closed

obenjiro mentioned this issue Mar 23, 2015

feat: Support for custom context and/or debug html files #1360

Closed

dignifiedquire added the type: backlog label May 16, 2015

dignifiedquire added PR exists and removed type: backlog labels Jun 26, 2015

dignifiedquire added this to the v1.0 milestone Jun 26, 2015

dignifiedquire mentioned this issue Jan 5, 2016

Added support for HTML5 mode #1770

Closed

dignifiedquire closed this as completed Mar 3, 2016

kwonoj mentioned this issue Apr 5, 2016

Enable browser test ReactiveX/rxjs#1579

Merged

Allow inserting source files in the HEAD / custom context.html #488

Allow inserting source files in the HEAD / custom context.html #488

Comments

vojtajina commented Apr 11, 2013

redaemn commented Apr 11, 2013

dignifiedquire commented Apr 11, 2013

filaraujo commented Apr 11, 2013

redaemn commented Apr 11, 2013

redaemn commented Apr 11, 2013

vojtajina commented Apr 12, 2013

pkozlowski-opensource commented Apr 13, 2013

filaraujo commented Apr 13, 2013

redaemn commented Apr 13, 2013

vojtajina commented Apr 13, 2013

redaemn commented Apr 13, 2013

pkozlowski-opensource commented Apr 13, 2013

vojtajina commented Apr 13, 2013

redaemn commented Apr 14, 2013

vojtajina commented Apr 15, 2013

vojtajina commented Apr 15, 2013

redaemn commented Apr 16, 2013

pkozlowski-opensource commented Apr 16, 2013

vojtajina commented Apr 19, 2013

guilhermeaiolfi commented Jul 25, 2013

vojtajina commented Jul 29, 2013

guilhermeaiolfi commented Jul 29, 2013

vojtajina commented Jul 30, 2013

filaraujo commented Jul 30, 2013

jcc8 commented Aug 5, 2013

franleplant commented Sep 27, 2013

patkujawa-wf commented May 1, 2014

caitp commented May 1, 2014

patkujawa-wf commented May 1, 2014

elkwood commented Jul 23, 2014

maxwellpeterson-wf commented Sep 15, 2014

obenjiro commented Mar 23, 2015

UnsungHero97 commented Sep 15, 2015

obenjiro commented Sep 15, 2015

UnsungHero97 commented Oct 8, 2015

T-vK commented Oct 19, 2015

rosenfeld commented Feb 10, 2016

dignifiedquire commented Mar 3, 2016