| Commit-Queue | +1 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Commit-Queue | +1 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
this.eventTracker_.removeAll();Do we want to keep this line (`this.eventTracker_.removeAll();`) in this class since we still have `this.eventTracker_.add(...)` call?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
this.eventTracker_.removeAll();Do we want to keep this line (`this.eventTracker_.removeAll();`) in this class since we still have `this.eventTracker_.add(...)` call?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Logic mostly lgtm, but what's the plan for adding test coverage? `omnibox_composebox.html.ts` and `omnibox_composebox.ts` have a lot of uncovered lines.
.toolMode="${this.inputState?.activeTool || ToolMode.kUnspecified}"optional: Might be cleaner to make a property for this in `omnibox_composebox.ts`, since we're using properties for the rest of these.
// TODO(crbug.com/486707998): Implement when carousel is added.
private addFileFromAttachment_(fileAttachment: FileAttachment) {
return fileAttachment;
}
// TODO(crbug.com/486707998): Implement when carousel is added.
private addTabFromAttachment_(tabAttachment: TabAttachment) {
return tabAttachment;
}What are these methods eventually supposed to do?
override shouldShowDivider(): boolean {optional: should this be placed with the other overrides near the top of this file (that start on line 66)?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Logic mostly lgtm, but what's the plan for adding test coverage? `omnibox_composebox.html.ts` and `omnibox_composebox.ts` have a lot of uncovered lines.
Added a few tests. There isn't too much we can test right now since only the input and dropdown exist right now.
.toolMode="${this.inputState?.activeTool || ToolMode.kUnspecified}"optional: Might be cleaner to make a property for this in `omnibox_composebox.ts`, since we're using properties for the rest of these.
That's a fair point. I prefer to keep it this way so we don't have to update the property in the lifecycle methods. We could make a computeToolMode but that also seems unnecessary.
// TODO(crbug.com/486707998): Implement when carousel is added.
private addFileFromAttachment_(fileAttachment: FileAttachment) {
return fileAttachment;
}
// TODO(crbug.com/486707998): Implement when carousel is added.
private addTabFromAttachment_(tabAttachment: TabAttachment) {
return tabAttachment;
}What are these methods eventually supposed to do?
These are for uploading files and tabs. I left them unimplemented so that the addSearchContext method could be kept the unchanged.
override shouldShowDivider(): boolean {optional: should this be placed with the other overrides near the top of this file (that start on line 66)?
Hmm I was planning to keep the Embedder-provided methods for DOM and Mojo access in one place and the methods for determining if an element should show in a separate place (below the functional methods). Lmk if you think it's better otherwise.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
// TODO(crbug.com/486707998): Implement when carousel is added.
private addFileFromAttachment_(fileAttachment: FileAttachment) {
return fileAttachment;
}
// TODO(crbug.com/486707998): Implement when carousel is added.
private addTabFromAttachment_(tabAttachment: TabAttachment) {
return tabAttachment;
}Marlon FaceyWhat are these methods eventually supposed to do?
These are for uploading files and tabs. I left them unimplemented so that the addSearchContext method could be kept the unchanged.
Ah ok got it.
override shouldShowDivider(): boolean {Marlon Faceyoptional: should this be placed with the other overrides near the top of this file (that start on line 66)?
Hmm I was planning to keep the Embedder-provided methods for DOM and Mojo access in one place and the methods for determining if an element should show in a separate place (below the functional methods). Lmk if you think it's better otherwise.
Got it, that makes sense to me.
await omniboxComposebox.updateComplete;In the past, the WebUI team has told me to prefer `microtasksFinished()` in tests... although the [official documentation](https://chromium.googlesource.com/chromium/src/+/HEAD/docs/webui/webui_using_lit.md#testing) does support `updateComplete` if the tests in this file can't use "microtasksFinished()". I wonder if all the `updateComplete` usages in this file could be replaced by "microtasksFinished()".
test(
'Shift+Enter allows inserting a newline when input is focused and not empty',
async () => {
const composeboxDiv =
omniboxComposebox.shadowRoot!.querySelector('#composebox');
assertTrue(!!composeboxDiv);
omniboxComposebox.input = 'Some text';
await omniboxComposebox.updateComplete;
const inputElement = omniboxComposebox.getInputElement();
inputElement.inputElement.focus();
let preventDefaultCalled = false;
const event = new KeyboardEvent('keydown', {
key: 'Enter',
shiftKey: true,
bubbles: true,
cancelable: true,
});
Object.defineProperty(event, 'preventDefault', {
value: () => {
preventDefaultCalled = true;
},
});
assertEquals(omniboxComposebox.getActiveElement(), inputElement);
composeboxDiv.dispatchEvent(event);
assertFalse(
preventDefaultCalled, 'preventDefault should not be called');
});nit: `#composebox` is exported in `omnibox_composebox.ts`, so you can use `omniboxComposebox.$.composebox` instead, at which point you would no longer need to assert its existence. And you would no longer need the message parts of the assertions, since there would only be one boolean assertion of the test
```suggestion
test(
'Shift+Enter allows inserting a newline when input is focused and not empty',
async () => {
omniboxComposebox.input = 'Some text';
await omniboxComposebox.updateComplete;
const inputElement = omniboxComposebox.getInputElement();
inputElement.inputElement.focus();
let preventDefaultCalled = false;
const event = new KeyboardEvent('keydown', {
key: 'Enter',
shiftKey: true,
bubbles: true,
cancelable: true,
});
Object.defineProperty(event, 'preventDefault', {
value: () => {
preventDefaultCalled = true;
},
});assertEquals(omniboxComposebox.getActiveElement(), inputElement);
const composeboxDiv = omniboxComposebox.$.composebox;
composeboxDiv.dispatchEvent(event);
assertFalse(preventDefaultCalled);
});
```
'Enter prevents inserting a newline and attempts to submit query when focus is not in dropdown',nit: two characters over the limit, consider shortening or breaking up into two lines
```suggestion
'Enter prevents inserting a newline and attempts to submit query when focus not in dropdown',
```
await omniboxComposebox.updateComplete;Out of curiousity, does this test fail without this line? Same for line 170.
${this.shouldShowSubmitButton() && this.searchboxLayoutMode === 'TallBottomContext' ? html`optional (out of CL's scope): I think the "html" part of this line goes over the character limit.
| Commit-Queue | +1 |
In the past, the WebUI team has told me to prefer `microtasksFinished()` in tests... although the [official documentation](https://chromium.googlesource.com/chromium/src/+/HEAD/docs/webui/webui_using_lit.md#testing) does support `updateComplete` if the tests in this file can't use "microtasksFinished()". I wonder if all the `updateComplete` usages in this file could be replaced by "microtasksFinished()".
Done
test(Done
'Enter prevents inserting a newline and attempts to submit query when focus is not in dropdown',nit: two characters over the limit, consider shortening or breaking up into two lines
```suggestion
'Enter prevents inserting a newline and attempts to submit query when focus not in dropdown',
```
Done
Out of curiousity, does this test fail without this line? Same for line 170.
Done
${this.shouldShowSubmitButton() && this.searchboxLayoutMode === 'TallBottomContext' ? html`optional (out of CL's scope): I think the "html" part of this line goes over the character limit.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Will wait for dry run to pass before stamping
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
https://screencast/cast/NTM3MjYwNTUxODMxNTUyMHw5NTgyYjM3Mi03Ywnit: http
let preventDefaultCalled = false;
const event = new KeyboardEvent('keydown', {
key: 'Enter',
shiftKey: true,
bubbles: true,
cancelable: true,
});nit: I'm having trouble following the AAA structure, understand that it might be unavoidable for the sections to interchange a few times, but maybe comments will help. Similar for the two tests below.
onAutocompleteResultChanged(result: AutocompleteResult) {Checking if we still need this method in `composebox.ts`, or will it be removed in a future CL? Similar for any other method that was moved over to the mixin and not removed from `composebox.ts`.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Commit-Queue | +1 |
https://screencast/cast/NTM3MjYwNTUxODMxNTUyMHw5NTgyYjM3Mi03YwMarlon Faceynit: http
Done
let preventDefaultCalled = false;
const event = new KeyboardEvent('keydown', {
key: 'Enter',
shiftKey: true,
bubbles: true,
cancelable: true,
});nit: I'm having trouble following the AAA structure, understand that it might be unavoidable for the sections to interchange a few times, but maybe comments will help. Similar for the two tests below.
Is it more clear with the comments now?
onAutocompleteResultChanged(result: AutocompleteResult) {Checking if we still need this method in `composebox.ts`, or will it be removed in a future CL? Similar for any other method that was moved over to the mixin and not removed from `composebox.ts`.
There are some embedder specific portions of this in composebox.ts. So I left the implementation in composebox.ts to prevent regressions.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
let preventDefaultCalled = false;
const event = new KeyboardEvent('keydown', {
key: 'Enter',
shiftKey: true,
bubbles: true,
cancelable: true,
});Marlon Faceynit: I'm having trouble following the AAA structure, understand that it might be unavoidable for the sections to interchange a few times, but maybe comments will help. Similar for the two tests below.
Is it more clear with the comments now?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Commit-Queue | +2 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
27 is the latest approved patch-set.
No files were changed between the latest approved patch-set and the submitted one.
[Omnibox Next] Add context entrypoint and dropdown
Add the context entrypoint and dropdown to the omnibox composebox fork.
Moves logic to the mixin that is needed to determine visibility of
certain elements. This does not contain the actual context entrypoint
just the parent container as of now. It also moves some lifecycle
methods to the mixin.
http://screencast/cast/NTM3MjYwNTUxODMxNTUyMHw5NTgyYjM3Mi03Yw
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |