On the June 24th commit, cookie_jar.rb file. http://github.com/tenderlove/mechanize/blob/0cb78c906ea339e16829636be47fe35b5dc8be6f/lib/www/mechanize/cookie_jar.rb

On the #add method

  def add(uri, cookie)
    return unless uri.host =~ /#{CookieJar.strip_port(cookie.domain)}$/i

    normal_domain = cookie.domain.downcase

    unless @jar.has_key?(normal_domain)
      @jar[normal_domain] = Hash.new { |h,k| h[k] = {} }
    end

    @jar[normal_domain][cookie.path][cookie.name] = cookie
    cleanup
    cookie
  end

I sometimes get an error on

   @jar[normal_domain][cookie.path][cookie.name] = cookie

complaining about "[]= called on nil object".

I suspect that when a cookie_jar is loaded from YAML, the default value for @jar[normal_domain] is not being correctly set. I'm currently adding

 @jar[normal_domain][cookie.path] ||= {}
 @jar[normal_domain][cookie.path][cookie.name] = cookie

I made support for NTLM - see my blog here for the gem I made and you can work out what I did so you can add it in a nice way: http://www.mindflowsolutions.net/2009/5/21/ruby-ntlm-mechanize

I tried to subclass WWW::Mechanize, but got errors that parser was not defined. It turned out, that @html_parser has no default when subclassing, probably because it is not in the initialize method. So I had to define the parser myself, but would have expected it to use the default one.

This problem is easily solved by editing the gemspec file and removing all references to the subdirectory 'www'

Results in various failures, 'Rescuing EOF error' or 'wrong status line'. I traced the problem to the ssl_resolver.rb line 23. This checks ! ssl.frozen? I remember this being an issue in earlier version of mechanize. I removed the check and things are dandy again. Hardly a solution.

I'm using Ruby 1.9.1p129 and the very latest Mechanize 0.9.3 gem build directly from source.

[gluenow.com ~/gluenow/current]$ gem list | grep mechanize
 mechanize (0.9.3)
[gluenow.com ~/gluenow/current]$ gem list | grep nokogiri
 nokogiri (1.3.3)
[gluenow.com ~/gluenow/current]$ ruby script/console production
 Loading production environment (Rails 2.2.2)
 WARNING: Nokogiri was built against LibXML version 2.6.30, but has dynamically loaded 2.6.31

...

 >> page = agent.submit(login_form)
 TypeError: can't convert nil into String
    from /opt/local/lib/ruby/gems/1.8/gems/mechanize-0.9.3/lib/www/mechanize/util.rb:40:in `iconv'
    from /opt/local/lib/ruby/gems/1.8/gems/mechanize-0.9.3/lib/www/mechanize/util.rb:40:in `from_native_charset'
    from /opt/local/lib/ruby/gems/1.8/gems/mechanize-0.9.3/lib/www/mechanize/form.rb:152:in `from_native_charset'
    from /opt/local/lib/ruby/gems/1.8/gems/mechanize-0.9.3/lib/www/mechanize/form.rb:144:in `proc_query'
    from /opt/local/lib/ruby/gems/1.8/gems/mechanize-0.9.3/lib/www/mechanize/form.rb:143:in `map'
    from /opt/local/lib/ruby/gems/1.8/gems/mechanize-0.9.3/lib/www/mechanize/form.rb:143:in `proc_query'
    from /opt/local/lib/ruby/gems/1.8/gems/mechanize-0.9.3/lib/www/mechanize/form.rb:166:in `build_query'
    from /opt/local/lib/ruby/gems/1.8/gems/mechanize-0.9.3/lib/www/mechanize/form.rb:165:in `each'
    from /opt/local/lib/ruby/gems/1.8/gems/mechanize-0.9.3/lib/www/mechanize/form.rb:165:in `build_query'
    from /opt/local/lib/ruby/gems/1.8/gems/mechanize-0.9.3/lib/www/mechanize/form.rb:214:in `request_data'
    from /opt/local/lib/ruby/gems/1.8/gems/mechanize-0.9.3/lib/www/mechanize.rb:401:in `post_form'
    from /opt/local/lib/ruby/gems/1.8/gems/mechanize-0.9.3/lib/www/mechanize.rb:344:in `submit'
    from (irb):9

patched, working after
in mechanize-0.9.3/lib/www/mechanize/util.rb
BEFORE

 40              Iconv.iconv(code, "UTF-8", s).join("")

AFTER

 40              Iconv.iconv(code.to_s, "UTF-8", s.to_s).join("")

scanning rubyforge
/Library/Ruby/Gems/1.8/gems/rubyforge-1.0.4/lib/rubyforge/client.rb:24:in `tmp_dh_callback=': can't modify frozen object (TypeError)

from /Library/Ruby/Gems/1.8/gems/rubyforge-1.0.4/lib/rubyforge/client.rb:24:in `use_ssl='
from /Library/Ruby/Gems/1.8/gems/mechanize-0.9.3/lib/www/mechanize/chain/ssl_resolver.rb:25:in `handle'
from /Library/Ruby/Gems/1.8/gems/mechanize-0.9.3/lib/www/mechanize/chain.rb:30:in `pass'
from /Library/Ruby/Gems/1.8/gems/mechanize-0.9.3/lib/www/mechanize/chain/handler.rb:6:in `handle'
from /Library/Ruby/Gems/1.8/gems/mechanize-0.9.3/lib/www/mechanize/chain/connection_resolver.rb:73:in `handle'
from /Library/Ruby/Gems/1.8/gems/mechanize-0.9.3/lib/www/mechanize/chain.rb:30:in `pass'
from /Library/Ruby/Gems/1.8/gems/mechanize-0.9.3/lib/www/mechanize/chain/handler.rb:6:in `handle'
from /Library/Ruby/Gems/1.8/gems/mechanize-0.9.3/lib/www/mechanize/chain/request_resolver.rb:27:in `handle'
 ... 18 levels...
from /Library/Ruby/Gems/1.8/gems/omnifocus-1.2.0/lib/omnifocus.rb:53:in `run'
from /Library/Ruby/Gems/1.8/gems/omnifocus-1.2.0/bin/omnifocus:6
from /usr/bin/omnifocus:19:in `load'
from /usr/bin/omnifocus:19

It seems that if you have multiple form fields with the same name, Mechanize does not Do The Right Thing when submitting the form.

According to the rails API docs, the HTML spec says that the first field encountered with a given name should "win" and subsequent fields with that name should be ignored.

The result is that given HTML like this, the form submitted should only contain the checkbox, not the hidden field.

I've written a failing test case using that HTML, you can see it here. Both are contained in the commit at bleything/mechanize@60bbf4c, for which I've sent a pull request :)

I use ruby 1.8.7 (2008-08-11 patchlevel 72) [i386-mswin32] and mechanize (0.9.3), nokogiri (1.3.3)

SSL証明書が無効なサイトにつなぐと以下のエラーが起きます。

2009.08.20 15:50:47:error: can't modify frozen object
xxxxxxxxxxx/lib/ruby/1.8/net/https.rb:138:in verify_mode=' xxxxxxxxxxx/lib/ruby/1.8/net/https.rb:138:inverify_mode=' xxxxxxxxxxx/gems/mechanize-0.9.3/lib/www/mechanize/chain/ssl_resolver.rb:26:in handle' xxxxxxxxxxx/gems/mechanize-0.9.3/lib/www/mechanize/chain.rb:30:inpass' xxxxxxxxxxx/gems/mechanize-0.9.3/lib/www/mechanize/chain/handler.rb:6:in handle' xxxxxxxxxxx/gems/mechanize-0.9.3/lib/www/mechanize/chain/connection_resolver.rb:73:inhandle' xxxxxxxxxxx/gems/mechanize-0.9.3/lib/www/mechanize/chain.rb:30:in pass' xxxxxxxxxxx/gems/mechanize-0.9.3/lib/www/mechanize/chain/handler.rb:6:inhandle' xxxxxxxxxxx/gems/mechanize-0.9.3/lib/www/mechanize/chain/request_resolver.rb:27:in handle' xxxxxxxxxxx/gems/mechanize-0.9.3/lib/www/mechanize/chain.rb:30:inpass' xxxxxxxxxxx/gems/mechanize-0.9.3/lib/www/mechanize/chain/handler.rb:6:in handle' xxxxxxxxxxx/gems/mechanize-0.9.3/lib/www/mechanize/chain/parameter_resolver.rb:18:inhandle' xxxxxxxxxxx/gems/mechanize-0.9.3/lib/www/mechanize/chain.rb:30:in pass' xxxxxxxxxxx/gems/mechanize-0.9.3/lib/www/mechanize/chain/handler.rb:6:inhandle' xxxxxxxxxxx/gems/mechanize-0.9.3/lib/www/mechanize/chain/uri_resolver.rb:72:in handle' xxxxxxxxxxx/gems/mechanize-0.9.3/lib/www/mechanize/chain.rb:25:inhandle' xxxxxxxxxxx/gems/mechanize-0.9.3/lib/www/mechanize.rb:457:in fetch_page' xxxxxxxxxxx/gems/mechanize-0.9.3/lib/www/mechanize.rb:557:infetch_page' xxxxxxxxxxx/gems/mechanize-0.9.3/lib/www/mechanize.rb:238:in `get'

If follow_meta_refresh is turned on and body of html page has meta tag for meta-refresh,
mechanize try to follow link on it.
Mechanize-0.9.3 has this issue

There seems to be a bug when using pretty print on responses from request methods, but only classes inherited from WWW::Mechanize.

The following example causes an exception to be raised, and demonstrates that it only occurs
on inherited classes.

require 'mechanize' class TestMech < WWW::Mechanize; end p WWW::Mechanize.new.get('http://www.example.com') # This works just fine... p TestMech.new.get('http://www.example.com') # but not this.

Here it is in IRB, along the first few lines of the back-trace.

irb(main):001:0> require 'mechanize'
=> true irb(main):002:0> class TestMech < WWW::Mechanize;end
=> nil irb(main):003:0> x = TestMech.new.get 'http://www.google.com'
NoMethodError: undefined method `parse' for nil:NilClass

    from /Library/Ruby/Gems/1.8/gems/tenderlove-mechanize-0.9.3.20090623142847/lib/www/mechanize/page.rb:82:in `parser'
    from /Library/Ruby/Gems/1.8/gems/tenderlove-mechanize-0.9.3.20090623142847/lib/www/mechanize/page.rb:142:in `meta'
    from /Library/Ruby/Gems/1.8/gems/tenderlove-mechanize-0.9.3.20090623142847/lib/www/mechanize/inspect.rb:22:in `pretty_print'
    from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/prettyprint.rb:201:in `group'
    from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/prettyprint.rb:227:in `nest'
    from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/prettyprint.rb:200:in `group'

/Library/Ruby/Gems/1.8/gems/mechanize-0.9.3/lib/www/mechanize/chain/response_reader.rb:18: [BUG] Segmentation fault ruby 1.8.7 (2008-08-11 patchlevel 72) [universal-darwin10.0]

will gather further details

Currently mechanize raises an error (mechanize.rb line 610) if it sees an error code like 400 in the response. I'd like to use webrat + mechanize to automate live testing of my staging environment including error cases. So I would like to be able to configure Mechanize to just return the page as is rather than raising an error so that I can assert that a 400 status was returned as expected.

Something like:

raise ResponseCodeError.new(page), "Unhandled response", caller if raise_errors?
page

where Mechanize.raise_errors? would default to true.