522133 - [mozmill] testClearFormHistory.js fails because PopupAutoComplete has 3px padding in Ubuntu

Status: RESOLVED WORKSFORME

(Mozilla QA Graveyard :: Mozmill Tests, defect)

Description

[Gordon McCreight]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.3) Gecko/20090910 Ubuntu/9.04 (jaunty) Shiretoko/3.5.3
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2b1pre) Gecko/20091012 Namoroka/3.6b1pre

In Ubuntu Linux at least one of the Mozmill tests fail because there is a three
pixel padding between the autocomplete choices element and its surrounding
element, "PopupAutoComplete".  (The padding does not appear on Windows or the
Mac)

In other words, there is a three pixel difference between both the left and top
positions of the elements returned by these two methods of selecting the
autocomplete popup:

new elementslib.ID(controller.window.document, "PopupAutoComplete");

new elementslib.Lookup(controller.window.document,
'/id("main-window")/id("mainPopupSet")/id("PopupAutoComplete")/anon({"anonid":"tree"})/{"class":"autocomplete-treebody"}');

The two methods are used interchangeably by some mozmill-test authors, most
likely because there is no noticeable difference on Windows or the Mac.  In
Ubuntu, however, only the second one provides an element with the correct
coordinates for actual clicking.


Reproducible: Always

Comment 1

[Gordon McCreight]

Here's a raw changeset: http://bitbucket.org/gmccreight/mozmill-tests/changeset/740057d10c53/raw/mozmill-tests-740057d10c53.diff

Comment 2

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

Gordon, that's an interesting thing. I have no idea why we have a padding on Linux. Do other applications are using this padding too or is it specific for Firefox? If it's the latter case I would call it a bug we should fix.

I'm a bit worried about the usage of child nodes of this tree element in that way. We should avoid that if possible. I can see two possible alternatives:

1. Use the pixels as further parameters for the click function so we don't click at (1,1) but lets say for safety at (5,5).

2. Remove the whole click function call and replace it with a keypress of VK_RETURN.

The second alternative should be much more robust.

We should also update the other tests under testFormManager to use the popup instead of the treebody. In disableFormManager we could check for the popup open state so we don't have to call assertNodeNotExist.

Further it would be great when you could reduce the sleep values so the test will be run faster.

Comment 3

[Gordon McCreight]

> Do other applications are using this padding too or is it specific for
Firefox?

The "Dictionary" application has a similar dropdown.  It also appears to have padding around the choices, but it appears to be a smaller padding (perhaps 1 or 2 pixels).  In any case, it doesn't appear to be a Firefox specific trait.

> The second alternative (using VK_RETURN) should be much more robust.

I agree.  Any technique that avoids deep lookup expressions would be more robust, given the propensity for chrome selector paths to change over time (I just finished up fixing another test that broke because of such a change... more details in another bug which I'll post soon).  I actually used the VK_RETURN for another test I'm developing from scratch.  That said, I think there's value in taking a heterogeneous approach to testing elements.  It certainly exercises the test framework more, and can, as in cases like this one, help bring things to our attention.  I think we should favor using the browser as a person would over focusing on test robustness.  For that reason, I think I like your #1 suggestion better.  If you agree, I'd be happy to add optional pixel parameters to the click method... just let me know.

Comment 4

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

(In reply to comment #3)
> > Do other applications are using this padding too or is it specific for
> Firefox?
> 
> The "Dictionary" application has a similar dropdown.  It also appears to have
> padding around the choices, but it appears to be a smaller padding (perhaps 1
> or 2 pixels).  In any case, it doesn't appear to be a Firefox specific trait.

Yeah, you can even see those paddings while navigating through the menu entries of the main menu. Looks like that each menupopup has the 2-3px assigned.

> VK_RETURN for another test I'm developing from scratch.  That said, I think
> there's value in taking a heterogeneous approach to testing elements.  It
> certainly exercises the test framework more, and can, as in cases like this
> one, help bring things to our attention.  I think we should favor using the
> browser as a person would over focusing on test robustness.  For that reason, I
> think I like your #1 suggestion better.  If you agree, I'd be happy to add
> optional pixel parameters to the click method... just let me know.

I believe that most of the time users are using return to select the item. So we should always use the keypress except one case where we select the appropriate item via a mouse click. Given the tests which are in our repository and those which will follow we should do the click test in the basic form test. All other tests should use the keypress.

Can you update all the tests under testFormManager to cover that? Please add a comment in the basic test why we use another approach there.

For upcoming bug reports please add the "[mozmill]" prefix to the summary of the bug and place it in the appropriate component. If you don't know the right place feel free to ask on IRC. I'm looking forward to upcoming patches from you. Thanks!

Comment 5

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

Hi Gordon, I haven't heard from you for a couple of weeks. I just want to ask how this work is going? Do you have time to work on it? I would appreciate it. Thanks.

Comment 6

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

Mass move of Mozmill Test related project bugs to newly created components. You can filter out those emails by using "Mozmill-Tests-to-MozillaQA" as criteria.

Comment 7

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

Never seen this test failure again in the last year. Should have been fixed now, that we middle click an element.