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

RESOLVED INVALID

Status

Mozilla QA
Mozmill Tests
RESOLVED INVALID
3 years ago
3 years ago

People

(Reporter: Daniel Gherasim, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

1.27 KB, application/javascript
Details
(Reporter)

Description

3 years ago
Created attachment 8495898 [details]
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.
(Reporter)

Comment 1

3 years ago
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.
Flags: needinfo?(hskupin)
Flags: needinfo?(andrei.eftimie)
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.
Flags: needinfo?(hskupin)
(Reporter)

Comment 3

3 years ago
(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.
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.
(Reporter)

Comment 5

3 years ago
(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.
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.
(Reporter)

Comment 7

3 years ago
(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).
(Reporter)

Comment 8

3 years ago
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.
(Reporter)

Updated

3 years ago
Hardware: ARM → All

Comment 9

3 years ago
I'll have a look on Monday

Comment 10

3 years ago
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
Flags: needinfo?(andrei.eftimie)
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.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → INVALID
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.
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.
You need to log in before you can comment on or make changes to this bug.