1073483 - Discover a way to handle hidden elements in a page (e.g. elements from the tabbed preferences page)

Status: RESOLVED INVALID

(Mozilla QA Graveyard :: Mozmill Tests, defect)

Description

[Daniel Gherasim]

Attachment: testCase.js

While working on the preferences library, I found out that we fail (intermitently but we do) on handling elements right after they are shown.

A simple test case is this:
1. Open preferences
2. Open sync pane
3. Click on the Sign In label
4. A new tab with the about:accounts page should open (but sometimes it fails)

Things I tried with no success:
1. Waiting for the hidden attribute of the parent to change
2. Waiting for the 'click' event on the element to be available ('click' in aElement.getNode())

It works with a sleep of about 100ms.

Comment 1

[Daniel Gherasim]

Just to mention that the test case only works in code and it's not human reproducible. It happens if we do the steps really really fast.

Asking Andrei & Henrik maybe they can think of an solution or an idea I could test.

Comment 2

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

Not sure why a hidden element has something to do with this link not being able to receive click events. Those are different things. Also which preferences do you mean? The old style or the new about:preferences tab page? The former is known to be not working correctly when switching wizard pages.

Comment 3

[Daniel Gherasim]

(In reply to Henrik Skupin (:whimboo) from comment #2)
> Not sure why a hidden element has something to do with this link not being
> able to receive click events. Those are different things. Also which
> preferences do you mean? The old style or the new about:preferences tab
> page? The former is known to be not working correctly when switching wizard
> pages.

It's about the new preferences in-content page.
Well the SignIn clickable 'label' it's hidden (thorugh it's wrapper) untill we open the 'sync' pane.

Comment 4

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

In the test you are not waiting for the sync page to be selected. That's a must do before you can access any elements inside the page.

Comment 5

[Daniel Gherasim]

(In reply to Henrik Skupin (:whimboo) from comment #4)
> In the test you are not waiting for the sync page to be selected. That's a
> must do before you can access any elements inside the page.

What do you mean by waiting for the sync page to be selected (besides waiting for the all sync page elements to be shown) ?
Do you reffer to wait for the "selected" attribute of the "category-sync" button? 
I did that and it's still not working.

Comment 6

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

No, I'm talking about the deck in this case with the id 'weavePrefsDeck', which has an attribute called hidden. This should be empty. The buttons on the left side will always be faster than the right deck/preferences pane to be loaded/displayed.

Comment 7

[Daniel Gherasim]

(In reply to Henrik Skupin (:whimboo) from comment #6)
> No, I'm talking about the deck in this case with the id 'weavePrefsDeck',
> which has an attribute called hidden. This should be empty. The buttons on
> the left side will always be faster than the right deck/preferences pane to
> be loaded/displayed.

That's exactly what we are doing in waitForHiddenAttribute. (waiting for the 'header-sync' & 'weavePrefsDeck' hidden attributes).

Comment 8

[Daniel Gherasim]

So I missed to say that there is no wrapper around each page :(. 
For any of the page, it's content is defined through the "data-category" attribute.

Comment 9

[Andrei Eftimie]

I'll have a look on Monday

Comment 10

[Andrei Eftimie]

This testcase might be flawed. I can reproduce the issue fine (100%) if I hog all my CPU cores.
But the failure cause for me is that we're attempting to click on the SignIn element when the previous page is still on.

We might need to have all related code (that waits for the page and for all elements) to catch if there's is another problem with this link.

===

I initially thought that we're attempting to click before the events gets attached to the element:
http://dxr.mozilla.org/mozilla-central/source/browser/components/preferences/in-content/sync.js#166-169

To properly test this we'll need to correctly wait for the "page" to load as we do in bug 1005811

Comment 11

[Cosmin Malutan, [:cosmin-malutan]]

Changing the categories happens synchronously and we shouldn't wait for any events, we have to wait for Initialized event and for "weave:service:ready" observer on the first opening as Jared suggested in bug 1083094 comment 20.

Comment 12

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

Nothing nowadays happens synchronously due to performance improvements. So I do not understand your last comment. Everything we have to wait for are asynchronously fired events, whereby one is an observer notification.

Comment 13

[Cosmin Malutan, [:cosmin-malutan]]

After opening the preferences pane first time, there is no need to wait for something else while changing the categories. For the two events we have to wait only when we open the preferences pane.