503192 - Improvements for accessing DOM nodes - get rid of lone XPath/Lookup strings

Status: RESOLVED WONTFIX

(Mozilla QA Graveyard :: Mozmill Tests, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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?

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+2]]

> (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.

Comment 2

[Dão Gottwald [:dao]]

(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.

Comment 3

[Mikeal Rogers [:mikeal] (mrogers@)]

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.

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+2]]

With bug 605343 implemented we should be able to get rid of all Lookup and XPath element getters for chrome tests.

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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.

Comment 6

[Jonathan French (:jfrench)]

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.

Comment 7

[Jonathan French (:jfrench)]

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

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Mozmill tests are no longer in use. So closing this bug.