Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement a means to communicate ATTA readiness and other environment details #9

Open
halindrome opened this issue Sep 18, 2016 · 3 comments

Comments

@halindrome
Copy link
Member

In the ATK ATTA branch at

# HACK to give us sufficient time to receive the document:load-complete
# accessibility event and compare it to the URL we set above.
@joanmarie mentions the hack that was required to ensure the DOMContentLoaded event has been received by the ATTA before we start testing.

The logic in the ATTAcomm.js library is to wait until the DOM Content is loaded (along with any other external test files) before doing ANYTHING. At that point, the library calls the "go" method, which then executes the following logic:

Send the "start" message to the ATTA

If no connection, no response, or a response that at all indicates the ATTA is not ready, to into manual testing mode.

Otherwise, go through each step in the list of tests in order, sending them to the ATTA and waiting for a reply or processing them locally, depending upon the type of step.

When all the steps are complete, send an 'end' message to the ATTA so it knows this test is terminating in case there is any cleanup needed (probably not, but it just seemed polite)

So... is there some way to delay the send of that start message so that the underlying system has an opportunity to get the windows painted etc? A .1 second delay or something to relinquish the processing and let the browser do its thing?

@joanmarie
Copy link
Collaborator

I believe we're also going to need a "I'm ready" mechanism during run_tests() when processing the accessibility event emission.

And in retrospect, perhaps I should remove the "HACK" comment. Because what that "hack" does IS the delay you're talking about. But in most cases one will hopefully not need a full second. And, while I don't anticipate this, imagine a scenario in which the test includes a crazy amount of DOM mutation. Then it might take the user agent and/or the A11y infrastructure (e.g. AT-SPI2 registry) more than 1 second. A "I'm ready"-based delay seems like the way to go.

That said, what I tried before doing the "hack" is not update the response until we were ready via a GLib timeout ("Don't call us; we'll call you."). That failed because as soon as start_test() finished, the test run proceeds. So "HACK" should be read to mean "Is this really we have to do? Worry about it later."

@halindrome
Copy link
Member Author

Ahh... so prior to each "step" maybe a round trip that asks "ATTA are you ready for me to proceed?" that responds when it is. RIght now those queries have a timeout that is quite long so it should work fine. Just a little more traffic but it is to localhost so... who really cares?

halindrome pushed a commit that referenced this issue Sep 20, 2016
Catch up to base repository
@joanmarie joanmarie changed the title Improve reliability of ATTAs? Implement a means to communicate ATTA readiness and other environment details Sep 25, 2016
@joanmarie
Copy link
Collaborator

(Updating the title)

In addition to readiness, there may be some other test-environment details we wish to convey. One that springs to mind is user agent version info. This might include things like:

  • Application name (Firefox, Nightly, SeaMonkey, etc.)
  • Toolkit name and version (e.g. Gecko 52.1)
  • Unique build details, if available (Date, sha, etc.)

When you ask the ATTA if it is ready for you to proceed, the ATTA could presumably include the above details in its response.

Regarding more traffic, but it's localhost: I agree completely. If there is anyone who cares, we could have an adjustable timeout after which we check again.

halindrome pushed a commit that referenced this issue May 9, 2017
Fix handling of responses to match spec
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants