Skip to content

Check for node type before calling normalize.#491

Closed
andrewplummer wants to merge 4 commits intojsdom:masterfrom
andrewplummer:master
Closed

Check for node type before calling normalize.#491
andrewplummer wants to merge 4 commits intojsdom:masterfrom
andrewplummer:master

Conversation

@andrewplummer
Copy link
Copy Markdown
Contributor

Sugar defines a method normalize on strings. Lines 165-199 of html.js appear to step through the attributes of a node, and call a a normalize method that is intended to be defined elsewhere in an "attribute" object. That in itself should not be an issue, but it appears that certain attributes may in fact be strings. I am currently encountering this in the src attribute of img nodes, however interestingly not all node attributes exhibit this behavior, for example type attributes on input elements are fine. At any rate it seems that either strings are not intended here or n.normalize should be performing a type check before calling that method. The change I made is rather naive, and I wouldn't be surprised if there's a better check that can be performed, but it gets the job done for me.

Note that this is currently being tested using Apricot and node. This will fix andrewplummer/Sugar#188

@domenic
Copy link
Copy Markdown
Member

domenic commented Oct 5, 2012

Hi,

I don't quite understand what the problem is here. Does this only occur in the presence of libraries that mess with String.prototype? Don't those same libraries mess up the browser? If not, could you add a failing test, i.e. one that passes in all browsers but not in jsdom?

@andrewplummer
Copy link
Copy Markdown
Contributor Author

  1. That's correct, specifically the Sugar library, which extends prototypes (http://sugarjs.com)
  2. No it doesn't mess up the browser.

Will try to add a failing test. Thanks for the response.

@domenic
Copy link
Copy Markdown
Member

domenic commented Oct 5, 2012

Sounds good! Probably the right place to add the test is at the bottom of test/level2/html.js. (I'm still figuring my own way around the repo, to be honest.)

@andrewplummer
Copy link
Copy Markdown
Contributor Author

Okay, that should do it. I've confirmed that that test will fail without the fix.

Both the test and the fix are pretty minimal. The test should be fine, but I don't expect the fix to necessarily be ideal (but it does get the job done here).

Thank you for addressing this!

@domenic
Copy link
Copy Markdown
Member

domenic commented Oct 5, 2012

Merged, thanks!

@domenic domenic closed this Oct 5, 2012
@domenic
Copy link
Copy Markdown
Member

domenic commented Oct 5, 2012

Sorry, I had to revert this because it was causing test failures in level2/html. Please feel free to resubmit if you can make all the tests pass.

@domenic domenic reopened this Oct 5, 2012
@andrewplummer
Copy link
Copy Markdown
Contributor Author

ok I think this latest test should fix it... I'm now just doing a typeof comparison to make sure the attribute isn't a string. Again, I have a feeling that a "deeper" fix might be better here, but I'm simply not familiar with the larger picture of jsdom to do it.

@domenic domenic closed this in 1b342a1 Oct 7, 2012
@domenic
Copy link
Copy Markdown
Member

domenic commented Oct 7, 2012

OK cool, merged!

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Array#each overrides Apricot's each in Node

2 participants