I am looking for a solution that can work like the following code in Playwright.
page.click('input:right-of(:text("Username"))');
By using this command in Playwright, the input element on the right side of text Username will be clicked. I searched for a while but found that there seemed to be no handy equivalents in Cypress. Are there any approaches that can enable the possibility to select elements based on their positional relationships?
I think you can use
cy.contains('Username') // === :text("Username")
.next() // === :right-of(<previous subject>)
.click()
There may be subtle differences, like .contains() is a partial match and .next() is the next sibling in the DOM, not necessarily "right-of" by x coordinates.
You can add-in cypress-testing-library which has
cy.findByLabelText('Username').type('myname')
I haven't used it, but semantically seems to be what you are aiming for. Would be useful if relative positions change in mobile mode (e.g labels above).
A while back I implemented custom commands to assert relative positions of elements, as we were getting a lot of CSS regressions, but it's quite fiddly.
Related
I've tried nearly anything, The "Type Into" activity won't print plain text into the text box let alone a held variable. The textbox element in question is the update work items comment box in the acme-test website from the Level 3 RPA developer course. I am able to type into the box manually and the robot is able to find it (the cursor moves to the centre of the text box and the program continues). I've tried quite a lot, including using a click activity and then sending the string as hotkeys.
Most probably the issue is related to your selectors. Since you are on level 3 RPA developer course I assume you are using Reframework for the task and I believe because of comprehensive error handling capabilities of this template your application just continuous with the next item instead of crashing when it can't find the element.
To solve the selector issues I usually do the following:
Use partial selectors instead of full selectors
Use wildcards for dynamic parts of your selectors (* for replacing any number of characters, ? for replacing exactly 1 character)
You can also store the page you are working on in a Uipath.Core.Browser type variable to eliminate the need of reselecting browser.
Also keep in mind that if you have used basic recorder functionality of UI path it generates full selectors.
I know that styles have an attribute to allow/avoid changes in the text in which they are applied:
SCI_STYLESETCHANGEABLE(int style, bool changeable)
However, the documentation says "This is an experimental and incompletely implemented style attribute.", which seems it is not "production-ready"
I think there is another alternative, using "Indicators":
To protect a range of text, we could apply an specific indicator to it and in keydown event detect "del" & "backspace". If the character that follows current position (caret position) in "del" case or that precedes current position in "backspace" case has this indicator, then we must cancel the event and do not erase the text.
Which of this 2 alternatives is better? There is another better way?
Note: ScintillaNet is based on Scintilla and I assume that the extensive documentation of the last one is valid for both.
I share with you one of the responses in "scintilla-interest" google-groups that published Neil Hodgson, the creator of Scintilla.
[Ian G.]> SCI_STYLESETCHANGEABLE is what I tried initially before I resorted to writing this patch. The only real disadvantage I can see is that in cases like my own it doubles the number of styles needed because every visual style that can occur in a writeable region can also occur in a protected region, but I could live with that.
[Neil Hodgson] It would be better to use an indicator for protected areas since they are relatively space efficient and avoid doubling the number of styles.
complete post in scintilla-interest
I have am A-frame scene where a series of entities must become visible after the user has clicked one by one another group of entities. I’ve a system that allowed me to hide every element of this first series, but I cant figured out how to show the second series, mostly because the user could click the first series in any order.
I’ve been trying to adapt this idea: https://css-tricks.com/snippets/css/toggle-visibility-when-hiding-elements/, but It seems that the “visibililty” attribute does not work in A-Frame.
Thank you very much.
The rendered elements are not DOM elements, so CSS will have no effect here. To toggle the visibility, use setAttribute()
someElement.setAttribute('visible', false) // or true
Check it out here. Docs here.
Im using Nightwatch for e2e and Im finding these two command a little bit confusing given the name and explanation that comes with them.
.waitForElementVisible:
Waits a given time in milliseconds for an element to be visible in the page before performing any other commands or assertions.
What is the meaning of visible?
An element position in the footer, you need to scroll to see it, is it considered visible?
Does it mean visible in the DOM even if it is display:hidden, position:relative; left:20000px;, ...? Not actually visible for a user but dom is existing basically.
What is a modal view in on top of some content? Is it visible?
.waitForElementPresent:
Waits a given time in milliseconds for an element to be present in the page before performing any other commands or assertions.
What is the meaning of present?
Existing in the DOM without taking into account if it's visible or not?
Is there any relation/implication between these two command?
If an element return truth for .waitForElementVisible does it imply that .waitForElementPresent will return true?
A lot of questions but maybe an explanation about how they work would solve all of these small questions...
Sometimes Im just getting errors and Im thinking that it might be my bad understanding of these two commands.
What is problem with definition ? You already answer your question.
An element position in the footer, you need to scroll to see it, is it considered visible?
No,you dont need to scroll to check it visible or not.May be you do need with some command but not with these visible/present commands.
Does it mean visible in the DOM even if it is display:hidden, position:relative; left:20000px;, ...? Not actually visible for a user but dom is existing basically.
Yes,it exists(means present) in the DOM but for some reason it is not visible yet
(bad connection,attribute value,...).
If an element return truth for .waitForElementVisible does it imply
that .waitForElementPresent will return true?
yes it will, if an element is visible = > it is present.
For usage , you can check out my an example answer here,it might help .
Login timeout
Basically an element might be present (as in loaded in DOM) but not visible (e.g. out of view so you might need to scroll to see it, or it might be hidden).
If you want to perform an action like a click on an element then you want to be using 'visible'.
I'm trying to modify Brian Reindel's Accessible News Slider plugin (sorry, it won't let me link to it and also to my work location), to allow a visitor to fill in multiple copies of a form, sliding back and forth between them. I need for the visitor to be able to add and delete copies of the form from the list. I've modified one of his examples and created a little function to add an element to the list. However, no matter how many times I call the function, it only adds one element, and the plugin is not aware of it; I can see it in the DOM Inspector, but that's it. What am I missing?
this is Brian. Since you're already using jQuery and the plugin, you would gain a great deal by using the library to append elements to the DOM within your custom function. I wanted to give you some guidance, since this is probably more work than you were inititally expecting. Here are some hopefully helpful tips:
The plugin calculates some wrapper
element widths based upon the number
of list items. If you add/remove list
items, then you would need to modify
the calculations that were made or
else it won't scroll properly. You'll probably experience the same types of issues for the click events on the next/previous buttons.
If you have events registered on
elements that you add/remove from the
DOM, then you will need to
re-register those events, since when
the elements are gone, so are the
events that were "bound" to them. It
doesn't look like this is your
problem though at this point.
If you're adding form elements to the
DOM on the fly using the "Add" link,
then the user's cursor focus is no
longer on the form elements, and the
slider is no longer really
accessible. As much as I love
plugging my own plugin, it was meant
mostly to demonstrate usable, custom styled accessible
JavaScript, and I'm not sure it is
flexible enough to do what you want
without some rework.
If you have more specific questions about how to do certain things to get you started on the right track, let me know, and I would be happy to help. Depending on how much you plan to use jQuery on your projects (and I highly recommend that you use it), try out the book Learning jQuery.