-
-
Notifications
You must be signed in to change notification settings - Fork 903
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
Object created by #dup puts validity error
to the console.
#1196
Comments
I have a very similar issue, many irrelevant “validity error : ID already defined” and don’t know how to get rid of it. 🙀 |
Looking into this! |
Hi, thanks for reporting this. This error message is emitted by Usually when creating a document (e.g., while parsing), we'll capture any errors and then attach them to the document's My understanding, after a cursory inspection of libxml2, is that when copying a document, libxml2 makes a duplicate of each node in the current document before reparenting it to the new document. So, momentarily, there is a violation of HTML's While I can't do anything within the confines of Nokogiri about the generation of the error message, we can certainly trap it and put it into |
Whoa, scratch the third paragraph -- there's just an error building the document due to how you structured the HTML markup. In any case, we'll fix the console emission. |
This will be in 1.6.5 out soon. |
I'm still getting a ton of these errors to my console with 1.6.5 ... did the fix make it in?
...etc Looks like the commit got removed. Shouldn't this be re-opened? |
Me too, the problem still remains in 1.6.5. |
Problem still remains for me too. I'm getting a stream of errors
|
I can still reproduce the bug on nokogiri 1.6.5. This is the minimal test case: test = Nokogiri::HTML.parse("<span id='test'></span>");
test.at_css('span').clone # emits element span: validity error : ID test already defined |
Having same problem as @conf. Suggestions? |
@flavorjones this ticket should be reopened and #1208 closed. |
Nod. |
Fix will be in the next release, in the next week or so. |
@flavorjones thank you! |
How do I get the next version - running bundler update still gives me 1.6.5 |
@henry74 It hasn’t been released yet, 1.6.5 is currently the last release available on RubyGems, that’s why bundler gives it. @flavorjones is currently working on it. |
1.6.6.1 was just released moments ago. |
Thanks @flavorjones. When I had looked on github, the latest version was 1.6.6 but I didn't see it on rubygems :-) Just funny timing... |
Hi, |
@Basher52 do you have a reproduction? If so, please file a new issue with the reproduction. |
What @zenspider said. This issue has been closed, let's please open a new one if you're seeing something unexpected. |
Thanks for the tip! I'm not quite sure, but it could be caused by nokogumbo instead of nokogiri... |
…nc behavior with JRuby. This was introduced due to sparklemotion#1196 and sparklemotion#1208 . However it turned out, that the change in libxml-2.9.2 was a regression, that was fixed in: https://bugzilla.gnome.org/show_bug.cgi?id=737840 and libxml-2.9.3. If I read the libxml sources right, it seems, that xmlDocCopyNode() is not intended to emit any such warnings at all. Only errors leading to a failure of the function are emitted. However these errors should be reported to ruby space in the form of exceptions (this is not yet implemented - currently either nil is returned or a generic error text is raised). This patch also synchronizes the behavior on MRI to that of JRuby, so that the error list is filled from the parser only and that it is shared after Document#dup .
…nc behavior with JRuby. This was introduced due to #1196 and #1208 . However it turned out, that the change in libxml-2.9.2 was a regression, that was fixed in: https://bugzilla.gnome.org/show_bug.cgi?id=737840 and libxml-2.9.3. If I read the libxml sources right, it seems, that xmlDocCopyNode() is not intended to emit any such warnings at all. Only errors leading to a failure of the function are emitted. However these errors should be reported to ruby space in the form of exceptions (this is not yet implemented - currently either nil is returned or a generic error text is raised). This patch also synchronizes the behavior on MRI to that of JRuby, so that the error list is filled from the parser only and that it is shared after Document#dup .
If you need the background, check flavorjones/loofah#79.
Here is a demo:
So the object created by #dup will puts error messages to the console. How to stop this behavior?
The text was updated successfully, but these errors were encountered: