Given by Dao on bug 500542: (In reply to comment #15) > The access is different as users will see it. We only work with DOM nodes and > don't wanna access any JS object. gBrowser is a DOM node, and so is gBrowser.selectedTab. Moreover, it's the interface we care about. We absolutely don't care about the fact that #main-window contains #browser, which contains #appcontent, which contains #content (that is gBrowser, btw), which contains an element whose anonid is "tabbox", which contains an element whose anonid is "strip", which contains an element whose anonid is "tabcontainer", which contains an element whose label is Foo (that is gBrowser.selectedTab, presumably), which contains an element with some random attributes. (In reply to comment #16) > It looks like the intention of the test is to validate the end user interface, > to this end the elements are looked up by resolving the interface node and > validating it's contents. > > If the intention of the test is to assert that this particular tab title is > viewable in this particular piece of interface then you'll need to stick with > the Lookup expression, That doesn't imply the need for an XPath-like expression. In fact, the given expression seems rather unsuited not only because of its maintenance cost, but because it doesn't verify that the matched tab is the one that was previously added. > And as a quick response to comment #12; it's QA's responsibility to update > mozmill tests when major changes land in the product, not developers. The > intention of mozmill test's are to automate QA's time, not to bog down the > development process. So mozmill tests won't appear on the mozilla-central tinderbox waterfall, or the tree won't be orange when they fail?
> (In reply to comment #15) > gBrowser is a DOM node, and so is gBrowser.selectedTab. Moreover, it's the So why I cannot see this node when using the DOM inspector on that window? > That doesn't imply the need for an XPath-like expression. In fact, the given > expression seems rather unsuited not only because of its maintenance cost, but > because it doesn't verify that the matched tab is the one that was previously > added. See above. I don't see gBrowser listed in the DOM nodes tree. We are working the same way as DOMi. So we don't know about gBrowser. > So mozmill tests won't appear on the mozilla-central tinderbox waterfall, or > the tree won't be orange when they fail? Mozmill will be included into the build system. See bug 457265.
(In reply to comment #1) > > (In reply to comment #15) > > gBrowser is a DOM node, and so is gBrowser.selectedTab. Moreover, it's the > > So why I cannot see this node when using the DOM inspector on that window? gBrowser is the <tabbrowser> element with the "content" id. gBrowser.selectedTab is the <tab> element inside of gBrowser that has the "selected" attribute. DOM inspector can directly access gBrowser via document.defaultView. > Mozmill will be included into the build system. See bug 457265. In that case, fragile and not-easily-maintainable mozmill tests will bog down the development process.
whimboo misunderstood that bug in relation to your comment. That build bug is to run mozmill tests continuously on buildbot, the details for how that does or does not effect the waterfall are not hashed out yet. This is actually a discussion that needs to happen on the dev-quality list but I'm afraid we'll have to wait until Clint gets back next week to have it. The details around the process we use for running and reacting to failures in mozmill tests has not been finalized and it is in my opinion a very bad idea to use a process that is identical to the mochitests.
With bug 605343 implemented we should be able to get rid of all Lookup and XPath element getters for chrome tests.
Depends on: 605343
Component: Mozmill → Mozmill Tests
Product: Testing → Mozilla QA
QA Contact: mozmill → mozmill-tests
Version: Trunk → unspecified
Whiteboard: [mozmill-refactor] → [mozmill-test-refactor]
Even that the test refactor project is dead, it would be still worth starting with the work on this bug - or to file dependent bugs for individual library modules. Jonathan, would you have the interest to check our library modules for lookup expressions and file dependent bugs for each of those? All of them should be mentored. It would be a good thing to get those in before the new Australis theme will land in Nightly builds.
Sure, I will file separate mentored bugs for each lib, and set depends on this bug. I will update here with that list, when done.
The above 'blockers' represent the libs involved for Lookup method removal. For visibility, they are: 879884 lib/downloads.js 879938 lib/prefs.js 879946 lib/search.js 879948 lib/software-update.js 879950 lib/tabs.js 879953 lib/toolbars.js
Mozmill tests are no longer in use. So closing this bug.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
QA Contact: hskupin
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.