I agree with you, but frame was intentionally designed that way and that's
what frame is being used. Raising the defect and fixing is not in my hand
according to this project.
Actually I worked in WATIR for first five years in my company but that was
watir-classic not selenium based watir. But
On Wednesday, December 13, 2017 at 10:23:58 AM UTC-8,
rajagopalanmadas...@gmail.com wrote:
>
> It's not possible to locate element without xpath in some places, xpath is
> pretty important and also unlike watir-classic, new WATIR which uses
> selenium-webdriver does the exceptional job with xpa
>
> You have more than one iframe with an id of 'SearchPanel' on the same
> page?
yes, Exactly, I have three frame with an id of 'SearchPanel'.
And yes, you can build this with Watir API without using XPath
here it is
@b.element(id: 'ApprovalManagerSearch').following_siblings[1].ifra
You have more than one iframe with an id of 'SearchPanel' on the same page?
And yes, you can build this with Watir API without using XPath
On Wed, Dec 13, 2017 at 7:23 PM, wrote:
> I am saying WATIR forms the xpath internally when you pass a locator which
> is not of selenium, for an example, t
I am saying WATIR forms the xpath internally when you pass a locator which
is not of selenium, for an example, text: locator
If you write a code
b.span(text: 'something').click
then WATIR would write the corresponding equivalent as below
driver.find_element(xpath: "//span[normalize-space()='s
Then How would I access your code? After accessing my code, should I use it
in WATIR library to check how is the performance? By the way where is your
new code?
On Wednesday, December 13, 2017 at 8:22:53 PM UTC+5:30, Justin Ko wrote:
>
> Sorry, no, these changes are not available in 6.10.1.
>
>
On Tuesday, December 12, 2017 at 9:56:46 AM UTC-8, rajagopalan madasami
wrote:
>
> I am using watir over selenium for two reasons, one reason is waiting
> timings are maintained by local language binding but selenium is
> maintaining timing from driver level , since selenium uses the timing from
Sorry, no, these changes are not available in 6.10.1.
There are still changes I want to do for the simplify_locator branch.
However, if the current state solves your problem, I can see if I get
something merged in sooner.
Justin
On Wednesday, December 13, 2017 at 1:42:05 AM UTC-5, rajagopal..
This change available in recent water 6.10.1?
On Tuesday, December 12, 2017 at 11:39:51 PM UTC+5:30, Justin Ko wrote:
>
> Rajagopalan, would you be able to see if the changes I have made in
> https://github.com/jkotests/watir/tree/simplify_locator fixes the
> performance problem for :visible_tex
Ugh, what a horrible design. Who wrote what we have now?
:)
Thanks for working to make it more straightforward.
On Tuesday, December 12, 2017 at 12:09:51 PM UTC-6, Justin Ko wrote:
>
> Rajagopalan, would you be able to see if the changes I have made in
> https://github.com/jkotests/watir/tre
Rajagopalan, would you be able to see if the changes I have made in
https://github.com/jkotests/watir/tree/simplify_locator fixes the
performance problem for :visible_text?
I think the problem is where we filter elements:
def filter_elements_by_locator(elements, visible = nil, visible_text = ni
I am using watir over selenium for two reasons, one reason is waiting
timings are maintained by local language binding but selenium is
maintaining timing from driver level , since selenium uses the timing from
driver level it differs from Firefox to Chrome, but since WATIR is
maintaining timing fro
Hey Chuck,
Especially with Watir 6, there are some good synchronization reasons to
prefer Watir over default selenium, even if not taking advantage of the
improved encapsulation of the subclasses or the more advanced locator
strategies. Though, not so many that it might not be worth it for him
bah... need to be able to edit... I confused using .link method of watir
with the :link locator type of Selenium... please disregard the confusion
over that sentence.
Point being however that you seem wedded to directly using .element and
selenium selection methods, so the question of why even
On Monday, December 11, 2017 at 10:29:52 PM UTC-8,
rajagopalanmadas...@gmail.com wrote:
>
> Can you please pay a little attention to the ongoing conversation? The
> conversation is not about using element() or using link() function, the
> conversation is about performance issue while I use vis
I'm confused. If the links are all the same text, are all visible, and
you only need the first one, why are you doing it this way?
Do you have example html to point to?
On Tue, Dec 12, 2017 at 7:31 AM, wrote:
> It's a railway ticket booking. There are many book now links are there and
> all of
It's a railway ticket booking. There are many book now links are there and
all of them are visible, but it has to choose the first one but it takes
too long time to click that link but while I use lick locator it does click
instantly.
On Monday, December 11, 2017 at 7:59:05 PM UTC+5:30, Titus
Can you please pay a little attention to the ongoing conversation? The
conversation is not about using element() or using link() function, the
conversation is about performance issue while I use visible text. I am
ready to use visible text If it does the good performance but it's not
doing it,
On Sunday, December 10, 2017 at 9:03:18 AM UTC-8, rajagopalan madasami
wrote:
>
> It is known that using :visible_text will not have the same performance.
> It has to iterate over elements, where as the Selenium ones would not. The
> benefit of :visible_text is that we can apply it across all el
Do you have example code for it taking that long? How many links are on the
page? Are you ruining locally or remotely?
--
--
Before posting, please read http://watir.com/support. In short: search before
you ask, be nice.
watir-general@googlegroups.com
http://groups.google.com/group/watir-gene
I understand your point, but it creates drastic performance difference, it
clicks the link after 2 to 3 minutes. Direct selenium link locator clicks
the link instantly. After wrapped in link() method, it clicks in 30
seconds(approximately). But my question, what other other element visible
text mat
We've already had this conversation on github. The consistency of the API is
much more important than this minor performance difference. Now all locators
will be treated exactly the same. It should be possible to implement
visible_text with the selenium locator, but a cursory look it was harder
>
> It is known that using :visible_text will not have the same performance.
It has to iterate over elements, where as the Selenium ones would not. The
benefit of :visible_text is that we can apply it across all element types,
not just links.
Yes, it is increasing the performance ! But still i
Yes, the plan is to remove :link, :link_text and :partial_link_text.
It is known that using :visible_text will not have the same performance. It
has to iterate over elements, where as the Selenium ones would not. The
benefit of :visible_text is that we can apply it across all element types,
not
24 matches
Mail list logo
