Watir 6.12.0 is now available on RubyGems. Three new contributors to Watir and several great new features available.
To install:
gem install watiror in your Gemfile:
gem "watir", "~> 6.12"New Contributors
First of all, thank you for taking the time to contribute:
- Aleksandar Kostadinov (akostad)
- Gijs Paulides (sjieg)
- John Fitisoff (jfitisoff)
Locating Elements with Custom Attributes
We recently allowed elements to be located with non-HTML5 compliant attributes.
These were required to Symbol instances like all other locators.
This element:
<div custom-attribute="foo">Foo</div>can be located with this code:
browser.div(custom_attribute: "foo")Since Symbol instances can’t have dashes, and most attributes use dashes instead
of underscores, we convert underscores to dashes. That means this element could
not be located:
<div custom_attribute="foo">Foo</div>To allow for underscores in custom attributes, Watir now supports
custom attributes as keys with String instances:
browser.element("custom_attribute" => "foo")Additional Element Features
Get Array of Element from an ElementCollection when using a Range
browser.divs[2..4] Get attribute values with Symbol as well as String values
browser.element.attribute_value :data_typeElement#flash can do a bunch more interesting things:
browser.element.flash :rainbow
browser.element.flash :slow
browser.element.flash :fast
browser.element.flash :long
browser.element.flash color: ["red", "white", "blue"]Logger
Users can now ignore specific warnings thrown by the Watir Logger.
As we move toward Watir 7, we are deprecating a number of features and throwing warnings that look like this:
2018-07-23 02:12:37 WARN Watir [DEPRECATION] ["wait_while_present"] Watir::Window#wait_while_present is deprecated. Use Watir::Window#wait_while(&:present?) instead.If you want to ignore this specific warning in your tests:
Watir.logger.ignore :fooIf you want to ignore all deprecation warnings in your tests:
Watir.logger.ignore :deprecationsWaits
Message values for waits can now be instances of Proc instead of just String
msg = Proc.new { |obj| "waiting for #{obj.inspect}" }
browser.element.wait_until message: msg, &:present?Also Element#wait_while_present and Element#wait_until_present now have
slightly different behaviors from the “to_proc” syntax of wait_while(&:present?) and wait_until(&:present?).
For most situations you want to use this latter syntax.
But what if you have this element:
<div class="here">Foo</div>and you locate it with this code:
element = browser.div(class: "here")and then some dynamic event caused the element class to change:
<div class="not-here">Foo</div>Because of how Watir caches elements for performance reasons, this will time out, because Watir will just keep verifying that the cached element is still there:
element.wait_while(&:present?)In this case we want the element to be looked up from scratch during the polling, which is what this does:
element.wait_while_presentSimilarly for #wait_until_present, the scenario is when an element is located, then goes away,
and you want to wait for it to come back.
This will throw a Stale Element exception:
element.wait_until(&:present?)This will return when the element has come back:
element.wait_until_presentDeprecations
1. Don’t use #present? or #visible? if you need to know if an element has gone stale, use
#stale? for this. Right now calling the same method multiple times can result in different
values even when the state of the DOM has not changed, which is undesirable.
2. Don’t use ordered parameters to locate elements.
All Watir location needs to be done as part of a Hash. This increases flexibility
to easily allow adding additional locators in the same selector and to improve
consistency across code bases.
# Bad:
browser.element(how, what)
# Good:
browser.element(how: what)3. I wrote a whole blog post on how we are changing #visible?
4. I discussed above under what special circumstances you should use
Element#wait_while_present and Element#wait_until_present. Right now these methods
can be used with non-Element classes, and support for that will soon be removed. It is safe to use
wait_while(&:present?) and wait_until(&:present?)
See the Changelog for the complete history of updates.