-
Notifications
You must be signed in to change notification settings - Fork 13
fix: account for ephemeral focus in enter precondition #619
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
|
|
@@ -363,4 +363,26 @@ suite('Keyboard navigation on Fields', function () { | |||||
| // The same field should still be focused | ||||||
| chai.assert.equal(await getFocusedFieldName(this.browser), 'BOOL'); | ||||||
| }); | ||||||
|
|
||||||
| test('Do not reopen field editor when handling enter to make a choice inside the editor', async function () { | ||||||
| // Open colour picker | ||||||
| await focusOnBlockField(this.browser, 'colour_picker_1', 'COLOUR'); | ||||||
| await this.browser.pause(PAUSE_TIME); | ||||||
| await this.browser.keys(Key.Enter); | ||||||
| await this.browser.pause(PAUSE_TIME); | ||||||
|
|
||||||
| // Move right to pick a new colour. | ||||||
| await keyRight(this.browser); | ||||||
| // Enter to choose. | ||||||
| await this.browser.keys(Key.Enter); | ||||||
|
|
||||||
| // Focus seems to take longer than a single pause to settle. | ||||||
| await this.browser.waitUntil( | ||||||
| () => | ||||||
| this.browser.execute(() => | ||||||
| document.activeElement?.classList.contains('blocklyActiveFocus'), | ||||||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
Is this needed to avoid a potential null?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't think so, e.g. testing in Node: > document = { activeElement: null }
{ activeElement: null }
> document.activeElement?.classList.contains('foo')
undefined
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. To add to matt's answer, if the activeElement exists, the classList will exist too (it might be an empty list, but it won't be null) https://developer.mozilla.org/en-US/docs/Web/API/Element/classList
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ah. This behaves differently in Kotlin land (where I'm much more familiar). There the '?' actually cascades. In this case, This will take me some time to get used to. :)
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, the way optional chaining works in JS is very pragmatic from the point of view of programmers but decidedly weird from the point of view of JS implementers. I found the parse trees that result from expressions with optional chaining to be extremely unintuitive—despite being (or perhaps because I was) already very familiar with ES5 parsing. |
||||||
| ), | ||||||
| {timeout: 1000}, | ||||||
| ); | ||||||
| }); | ||||||
| }); | ||||||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed for clarity as I had to read the code to learn that
options.readOnlywas mutated whensetIsReadOnlywas called.