Skip to content
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

nokogiri sax error handlers get fscked up when using libxml #87

Closed
deepfryed opened this issue Jun 22, 2009 · 4 comments
Closed

nokogiri sax error handlers get fscked up when using libxml #87

deepfryed opened this issue Jun 22, 2009 · 4 comments

Comments

@deepfryed
Copy link

http://pastie.org/520797

as demonstrated requiring libxml stuffs up nokogiri's error handlers. this is especially difficult to trace if your application is using nokogiri but one of the plugin uses libxml-ruby. this is not a bug per-se in nokogiri but i would like to see this ironed out or atleast listed as an issue in the documentation.

@tenderlove
Copy link
Member

Oh shit. This sucks. I'm sorry, I'll see what I can do to either circumvent libxml-ruby, or at the very least, document the problem.

@tenderlove
Copy link
Member

Unfortunately there isn't anything I can do about this problem. Libxml-ruby is setting a global C variable when you call that ruby method.

Since I can't stop you from calling that ruby code, there isn't much I can do about this except document the problem.

@deepfryed
Copy link
Author

thanks for looking into it. it's interesting, actually I don't call any method in libxml-ruby, just requiring it causes the problem. i expect some sort of global hook being used by libxml-ruby on being required to be the problem

@tenderlove
Copy link
Member

changing the global error function on SAX load. closed by d23fe2c

flavorjones added a commit that referenced this issue Dec 28, 2020
This was leading to loss of error capture on extremely short HTML docs
when encoding was not passed by the caller.

This call was introduced in d23fe2c (#87) for reasons that are
unclear, but we've come a long way with how we manage the global error
handlers and so I think we're OK to stop doing this now.
flavorjones added a commit that referenced this issue Dec 28, 2020
This was leading to loss of error capture on extremely short HTML docs
when encoding was not passed by the caller.

This call was introduced in d23fe2c (#87) for reasons that are
unclear, but we've come a long way with how we manage the global error
handlers and so I think we're OK to stop doing this now.
flavorjones added a commit that referenced this issue Dec 28, 2020
This was leading to loss of error capture on extremely short HTML docs
when encoding was not passed by the caller.

This call was introduced in d23fe2c (#87) for reasons that are
unclear, but we've come a long way with how we manage the global error
handlers and so I think we're OK to stop doing this now.
flavorjones added a commit that referenced this issue Jan 6, 2021
Note that this change regresses the behavior changed in 771164d which
we'll have to fix in an upcoming commit.

Related to #2168, #87
flavorjones added a commit that referenced this issue Jan 6, 2021
Note that this change regresses the behavior changed in 771164d which
we'll have to fix in an upcoming commit.

Related to #2168, #87
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants