Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Trying to resolve a conflict between testcases

1 view
Skip to first unread message

Dave Townsend

unread,
Sep 29, 2008, 12:31:09 AM9/29/08
to
I am attempting to develop a browser chrome test for
https://bugzilla.mozilla.org/show_bug.cgi?id=391728 and I'm hitting a
problem that I can't solve without further suggestions.

The testcase I have runs through a few tests of missing plugins one of
which involves opening and closing the add-ons manager window. It seems
that this action then causes the testcase from
https://bugzilla.mozilla.org/show_bug.cgi?id=427559 to fail because
focus no longer ends up where it expects it to.

My investigation suggests however that regardless of my testcase, the
focusedWindow and focusedElement are identical at the start of the test
for bug 427559, so it doesn't appear that my test is changing the focus
at all.

Specifically, without my test in place, at the start of 427559
focusedWindow is the browser.xul window, focusedElement is the urlbar.
When the test page in there loads focusedWindow is the content window,
focusedElement is the button in the page.
With my test in place the focus is the same at the start however after
the test page loads focusedWindow remains as the browser.xul window.
focusedElement moves correctly

Basically something about the webpage loading is causing the
focusedWindow to change from browser.xul to the content window.
Something about my testcase opening the add-ons manager is breaking that.

If I disable all browser chrome tests except for mine and 427559 then
everything passes. The test for 427559 is already disabled on Linux
because it randomly fails, and it looks like that random failure is the
same as the failure I am inducing.

So the questions are:

Is there something wrong with my test that needs fixing?
Is there something wrong with the test for 427559 that needs fixing
(given that it already randomly fails on Linux I'll guess yes)?
Is there some way I can debug this? I have stacks of the focusedWindow
change when my test isn't present but I can't figure out how to catch it
in the middle of the test run in a debugger.
What is the best way forward given that we really want to land by bug
for b1?

If you want to test this out yourself then you'll need to apply the two
remaining patches from 391728 and run the browser chrome tests.

Dave

Neil Deakin

unread,
Sep 29, 2008, 6:00:31 AM9/29/08
to
Dave Townsend wrote:

> Is there something wrong with my test that needs fixing?
> Is there something wrong with the test for 427559 that needs fixing
> (given that it already randomly fails on Linux I'll guess yes)?

Does either test listen for the load event? It's often better to listen
to the focus event on the root element (or the window) instead. A number
of existing tests do this.

Dave Townsend

unread,
Sep 29, 2008, 8:51:39 AM9/29/08
to

My test uses a window listener to detect the add-ons manager appearing,
then a load event to detect it loading, then the window listener again
to detect it closing. I did have to stick a timeout after the load to
allow the regular load handlers to run before I do my tests. Not sure if
using a focus event would help here.

The other test uses a load event on the content window, followed by a
timeout of 0 which apparently helped resolve some issues. Maybe I'll try
that with a focus listener instead to see what happens.

Dave Townsend

unread,
Sep 29, 2008, 9:23:50 AM9/29/08
to

No change it seems

Robert Kaiser

unread,
Sep 29, 2008, 11:57:32 AM9/29/08
to
Dave Townsend wrote:
> My test uses a window listener to detect the add-ons manager appearing,
> then a load event to detect it loading, then the window listener again
> to detect it closing. I did have to stick a timeout after the load to
> allow the regular load handlers to run before I do my tests. Not sure if
> using a focus event would help here.

Window listener reminds me of a problem I recently debugged and fixed:
Does your test correctly clean up and also remove this listener again
when finishing? If not, it will still fire for every following test,
which potentially makes other tests fail.

Robert kaiser

Dave Townsend

unread,
Sep 29, 2008, 12:13:32 PM9/29/08
to

Yeah it does clean itself up.

0 new messages