# Watir - determine order of the controls **URL:** \ **Category:** Ruby\ **Created:** [October 26, 2006, 8:17pm UTC](https://www.ruby-forum.com/t/watir-determine-order-of-the-controls/73748 "2006-10-26T20:17:50Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![pkspence](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/a88e57/32.png) [@pkspence](https://www.ruby-forum.com/u/pkspence)\ **Post date:** [October 26, 2006, 8:17pm UTC](https://www.ruby-forum.com/t/watir-determine-order-of-the-controls/73748/1 "2006-10-26T20:17:50Z")
I’ve written a ScreenScraper class that “harvests” all the HTML elements; textfields, checkboxes, radiobuttons, etc., from a web page and populates a SQL Server table. This is a process needed to fully automate the testing of a [ASP.NET](http://ASP.NET) app from a data-driven approach. The problem is that the developers that wrote the app did not use the “tabindex” property on any of the controls. Had they done so, the ScreenScraper class could’ve collected that information as well and we’d know in what order the controls have to be populated. Although it’s a valid test, under normal circumstances you wouldn’t want to click the “Login” button until both a username and password are provided. My question… Is there a way to collect a list of all the controls on a page _in the order they appear on the screen_? I suspect drilling into the DOM is going to be part of the solution. Just wondering if someone else has run into this issue and what they did to resolve it. No sense in re-inventing the wheel. An alternative would be a Ruby script that records the mouse clicks as each control is clicked, stuffing the “taborder” into a table, or some such. Thanks! ---
**Author:** ![pkspence](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/a88e57/32.png) [@pkspence](https://www.ruby-forum.com/u/pkspence)\ **Post date:** [October 26, 2006, 11:20pm UTC](https://www.ruby-forum.com/t/watir-determine-order-of-the-controls/73748/2 "2006-10-26T23:20:55Z")
On 10/26/06, Patrick S. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Thanks! > I don’t think this is a well-defined problem. The order in which > fields appear on screen is not deterministic with respect to the > source document; it can be affected by CSS and even by the user agent > (it’s possible to have field A below field B in Firefox, but above in > Internet Explorer). Considering tables & columns, even “before” and > “after” become ambiguous… how would you order the fields in the > following HTML table, with respect to screen layout? | | | | | | | You’ll probably need to explicitly define dependencies based on the field names. -Alex ---
**Author:** ![pkspence](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/a88e57/32.png) [@pkspence](https://www.ruby-forum.com/u/pkspence)\ **Post date:** [October 27, 2006, 5:07pm UTC](https://www.ruby-forum.com/t/watir-determine-order-of-the-controls/73748/3 "2006-10-27T17:07:49Z")
On 10/26/06, Patrick S. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > > following HTML table, with respect to screen layout? > > will be written to a SQL Server table upon each mouse click. This sounds > > like a really interesting project! Sorry if I was unlear; your description was well-stated, I was saying that your core question, “Is there a way to collect a list of all the controls on a page _in the order they appear on the screen_?” is not well-defined, because the order in which controls appear on the screen is not well-defined given a source document. Your “record-the-order” plan sounds like a good one. Good luck! -A ---
**Author:** ![pkspence](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/a88e57/32.png) [@pkspence](https://www.ruby-forum.com/u/pkspence)\ **Post date:** [October 26, 2006, 11:56pm UTC](https://www.ruby-forum.com/t/watir-determine-order-of-the-controls/73748/4 "2006-10-26T23:56:58Z")
Alex LeDonne wrote: > On 10/26/06, Patrick S. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > > > Thanks! > > I don’t think this is a well-defined problem. The order in which > > fields appear on screen is not deterministic with respect to the > > source document; it can be affected by CSS and even by the user agent > > (it’s possible to have field A below field B in Firefox, but above in > > Internet Explorer). Considering tables & columns, even “before” and > > “after” become ambiguous… how would you order the fields in the > > following HTML table, with respect to screen layout? > > > > If you’re referring to my question, I thought it the problem was defined > > quite clearly; here’s what I have, here’s what I need, how do I get > > there? As to CSS affecting the layout, you’re absolutely correct. The more I think about this, I believe my “alternative” approach would be a better solution. Even though it will involve someone going thru each page of the app and clicking on the controls _in the proper order_. However, this will only have to be done once as the “click order”, or “taborder”, will be written to a SQL Server table upon each mouse click. This sounds like a really interesting project! ---
**Author:** ![pkspence](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/a88e57/32.png) [@pkspence](https://www.ruby-forum.com/u/pkspence)\ **Post date:** [October 27, 2006, 10:30pm UTC](https://www.ruby-forum.com/t/watir-determine-order-of-the-controls/73748/5 "2006-10-27T22:30:32Z")
> As to CSS affecting the layout, you’re absolutely correct. The more I > think about this, I believe my “alternative” approach would be a better > solution. Even though it will involve someone going thru each page of > the app and clicking on the controls _in the proper order_. However, > this will only have to be done once as the “click order”, or “taborder”, > will be written to a SQL Server table upon each mouse click. This sounds > like a really interesting project! I wouldn’t be too hasty, there, those controls are going to change over time, breaking both your scripts and your database records. I’ve built a number of these sorts of things, and I find that it is better to define sets of paths through the application that accomplish particular objectives, as opposed to testing widget-by-widget. ---
**Author:** ![pkspence](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/a88e57/32.png) [@pkspence](https://www.ruby-forum.com/u/pkspence)\ **Post date:** [October 28, 2006, 2:40am UTC](https://www.ruby-forum.com/t/watir-determine-order-of-the-controls/73748/6 "2006-10-28T02:40:49Z")
> I wouldn’t be too hasty, there, those controls are going to change over > time, breaking both your scripts and your database records. > > I’ve built a number of these sorts of things, and I find that it is > better to define sets of paths through the application that accomplish > particular objectives, as opposed to testing widget-by-widget. Chris has a good point. Furthermore, most modern browsers “fix” HTML, by adding missing tags, etc. Testing that the HTML elements are correct might be better done at the HTTP layer. Hope that helps. -Jonathan ---
**Author:** ![pkspence](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/a88e57/32.png) [@pkspence](https://www.ruby-forum.com/u/pkspence)\ **Post date:** [October 27, 2006, 11:46pm UTC](https://www.ruby-forum.com/t/watir-determine-order-of-the-controls/73748/7 "2006-10-27T23:46:40Z")
> As to CSS affecting the layout, you’re absolutely correct. The more I > think about this, I believe my “alternative” approach would be a better > solution. Even though it will involve someone going thru each page of > the app and clicking on the controls _in the proper order_. However, > this will only have to be done once as the “click order”, or “taborder”, > will be written to a SQL Server table upon each mouse click. This sounds > like a really interesting project! I wouldn’t be too hasty, there, those controls are going to change over time, breaking both your scripts and your database records. I’ve built a number of these sorts of things, and I find that it is better to define sets of paths through the application that accomplish particular objectives, as opposed to testing widget-by-widget.