Open chrome prior to system tests#14260
Conversation
Theory: Chrome is busy with post install tasks, so start chrome in the background ahead of the tests. The first system test to run that requires chrome occasionally fails. This has been replicated on developer machines after chrome updates, however it is difficult to reproduce, and difficult to detect/recover-from in an automated way. It may be possible to handle this better within NVDA, however it seems to actually affect users infrequently, and they seem to be able to recover by waiting a few seconds and de/refocus chrome. In the mean time, the system tests failing delays development.
--lang=en-US was duplicated
| # This has been replicated on developer machines after chrome updates, | ||
| # however it is difficult to reproduce, and difficult to detect/recover-from | ||
| # in an automated way. | ||
| # It may be possible to handle this better within NVDA, however it seems to actually affect users |
There was a problem hiding this comment.
I do not understand this specific sentence. Any clarification?
There was a problem hiding this comment.
It's saying that the bug is legitimate, it has been replicated on developer environments, it is not only theoretical or a quirk of running on Appveyor. Despite it being a real issue, the problem occurs very rarely and working around the issue is very easy, the impact on users is minimal. We won't attempt to fix this given the small impact on users, and high time cost to investigate and fix. However, the issue does affect the system tests, occasionally causing the first chrome test to fail. This is a problem for developers, they have to wait for a new build. This change (starting chrome early) is an attempt to work around the problem, purely to prevent delays for developers.
There was a problem hiding this comment.
Clarification:
Despite it being a real issue, the problem occurs very rarely and working around the issue is very easy
Very easy for end users. When I have seen this occur, pressing alt+tab to bring a different app to the foreground, then return to chrome resolves the issue.
There was a problem hiding this comment.
This description is mixing two issues, hence my confusion:
- Chrome fails to start normally
- First Chrome test fails (due to 1.)
The normal user experience with Chrome and the behaviour of Chrome during system tests are also mixed in this paragraph and sometimes, it's unclear what apply to users and to system tests.
Maybe you could reword the paragraph like this (to be improved and described more precisely):
The first system test to run that requires chrome occasionally fails due to Chrome abnormal startup [please describe more precisely].
Chrome sometimes does not starts normally, preventing users to use it normally. This has been replicated on user machines after chrome updates,
however it is difficult to reproduce, and difficult to detect/recover-from
in an automated way in system tests.
It may be possible to work around this abnormal Chrome startup better within NVDA, however it seems to actually affect users
infrequently, and they seem to be able to recover by waiting a few seconds and de/refocus chrome.
In the mean time, the system tests failing delays development.
Explaining somewhere what happens
There was a problem hiding this comment.
occasionally fails due to Chrome abnormal startup
No, we don't know that for sure. All we know:
- Occasionally the first chrome system test on Appveyor fails. NVDA does not load a virtual buffer.
- Very rarely this symptom has been observed by developers on their own machines.
There was a problem hiding this comment.
@CyrilleB79 I've updated this explanation.
This comment was marked as outdated.
This comment was marked as outdated.
|
Dismissing the test failure: This is a symptom of another intermittent problem, an attempt to resolve is coming another PR. |
CyrilleB79
left a comment
There was a problem hiding this comment.
The explanation looks clearer now. Thanks.
Just a typo to fix.
Link to issue number:
Splitting up PR #14054
Summary of the issue:
The first system test to run that requires chrome occasionally fails.
This has been replicated on developer machines after chrome updates, however, it is difficult to reproduce, and difficult to detect/recover-from in an automated way.
Description of user facing changes
None
Description of development approach
Theory for cause:
Chrome is busy with post install tasks, so start chrome in the background ahead of the tests.
It may be possible to handle this better within NVDA, however it seems to actually affect users infrequently, and they seem to be able to recover by waiting a few seconds and de/refocus chrome.
In the meantime, the system tests failing delays development.
Testing strategy:
This will require many builds on appveyor to confirm an improvement.
Known issues with pull request:
This is intentionally working around an issue that may affect users.
Change log entries:
None
Code Review Checklist: