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
fix(client): Enable loading different file types when running in parent mode without iframe #3289
Merged
johnjbarton
merged 8 commits into
karma-runner:master
from
chan1cyrus2:fix-script-file-type-in-parent-mode
Apr 12, 2019
Merged
Changes from 1 commit
Commits
Show all changes
8 commits
Select commit
Hold shift + click to select a range
d39167c
fix(client): Includes attributes like type in script tags when runnin…
chan1cyrus2 cd0bf3c
fix(client): Enable loading different file types when running in pare…
chan1cyrus2 5fd685a
fix(client): Update comments on escaping character with special roles…
chan1cyrus2 699f8a5
fix(client): Fix comments
chan1cyrus2 cddb93c
fix(client): Use conditions to make the require changes.
43d9629
fix(client): Fix CLA
chan1cyrus2 905e464
fix(client): Fix CLA second try!
chan1cyrus2 e87e349
fix(client): Fix typo
chan1cyrus2 File filter
Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -66,8 +66,24 @@ function Karma (socket, iframe, opener, navigator, location) { | |
} else if (url !== 'about:blank') { | ||
var loadScript = function (idx) { | ||
if (idx < window.__karma__.scriptUrls.length) { | ||
var ele = document.createElement('script') | ||
ele.src = window.__karma__.scriptUrls[idx] | ||
var parser = new DOMParser() | ||
// Browsers don't like character <> in string when assigning | ||
// stringify json into a variable, so we replace them with escape | ||
// hex | ||
var string = window.__karma__.scriptUrls[idx] | ||
.replace(/\\x3C/g, '<') | ||
.replace(/\\x3E/g, '>') | ||
var doc = parser.parseFromString(string, 'text/html') | ||
var ele = doc.head.firstChild || doc.body.firstChild | ||
// script elements created by DomParser is marked as unexecutable, | ||
chan1cyrus2 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
// create a new script element manually and copy necessary properties | ||
// so it is executable | ||
if (ele.tagName && ele.tagName.toLowerCase() === 'script') { | ||
var tmp = ele | ||
ele = document.createElement('script') | ||
ele.src = tmp.src | ||
ele.crossOrigin = tmp.crossorigin | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is the different case significant? If yes please add a comment; if no please pick one. |
||
} | ||
ele.onload = function () { | ||
loadScript(idx + 1) | ||
} | ||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rather than "inanimate object does not like" can we say eg
// Escape characters with special roles in HTML that appear in the body of tags.
But I don't understand this. How can a DOM parser not support angle bracket parsing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's say we have only one file (bar/foo.js). We then construct this element that would like to add to the dom (<script type="text/javascript" src="/bar/foo.js" ></script>). When we embed this string into %SCRIPT_URL_ARRAY% in client_with_context.html. The html file will have a line look like this: window.karma.scriptUrls = ["<script type="text/javascript" src="/bar/foo.js" ></script>"]. When the browser parse the html file, they stop parsing once it reaches the character "<". They parse it and expect it as an open tag even though it is wrapped with double quotation. This happens on both Chrome and the lightweight browser I am using. Therefore I turn them to hex code which looks like this in the html: window.karma.scriptUrls = ["\x3Cscript type="text/javascript" src="/bar/foo.js" \x3E\x3C/script\x3E"]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't it be clearer to have the template be an array of objects:
[{type: "text/javascript", src: "/bar/foo.js" }, {...}]
Then in this code we walk the object and create the script tags. So no angle brackets in the template means no reason to encode then replace the angle brackets?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also thought about this approach too. However, the script tags html strings are constructed case by case in the middleware.
If this changes in the future, we have to update the logic to construct and reconstruct the script tag object too. I think that actually adds another layer of complexity and maintenance. Therefore, I prefer just escaping and de-escaping the generated string here (which I think also have closest logic to the regular case).