Bug 1747162 Comment 13 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Could not reproduce locally or try pushes (especially with MacOS... since I could not focus on `#downloadsHistory`).  So instead, I opted for another solution: removing the [`!openedManually`](https://searchfox.org/mozilla-central/source/browser/components/downloads/content/downloads.js#657,659) condition and testing this change locally on Ubuntu. Made a [try push](https://treeherder.mozilla.org/jobs?repo=try&revision=2a468289a0f9614a4a0d75fa1b6796ee99888762) with this change and also recorded how it behaves.

Given the following conditions:
1. downloads panel is empty
2. delay timer ends (in the video, `security.dialog_enable_delay` is set to 5 seconds)

... we end up focusing on the `#downloadsHistory` button. In `browser_documentnavigation.js`, we are supposed to be focused on [the url bar](https://searchfox.org/mozilla-central/source/browser/base/content/test/general/browser_documentnavigation.js#319-325). And, from there, we navigate backwards to the page's content using shift+F6. Before that can happen, the delay timer passes and we end up focusing on the downloads panel instead, messing up the order of focus.

I can think of two potential fixes:
1. addressing  flaky situation we found with bug 1747465
2. or simply setting `security.dialog_enable_delay` to 0 in the test `browser_documentnavigation.js`
Could not reproduce reliably locally or with try pushes (especially with MacOS... since I could not focus on `#downloadsHistory`).  So instead, I opted for another solution: removing the [`!openedManually`](https://searchfox.org/mozilla-central/source/browser/components/downloads/content/downloads.js#657,659) condition and testing this change locally on Ubuntu. Made a [try push](https://treeherder.mozilla.org/jobs?repo=try&revision=2a468289a0f9614a4a0d75fa1b6796ee99888762) with this change and also recorded how it behaves.

Given the following conditions:
1. downloads panel is empty
2. delay timer ends (in the video, `security.dialog_enable_delay` is set to 5 seconds)

... we end up focusing on the `#downloadsHistory` button. In `browser_documentnavigation.js`, we are supposed to be focused on [the url bar](https://searchfox.org/mozilla-central/source/browser/base/content/test/general/browser_documentnavigation.js#319-325). And, from there, we navigate backwards to the page's content using shift+F6. Before that can happen, the delay timer passes and we end up focusing on the downloads panel instead, messing up the order of focus.

I can think of two potential fixes:
1. addressing  flaky situation we found with bug 1747465
2. or simply setting `security.dialog_enable_delay` to 0 in the test `browser_documentnavigation.js`
Could not reproduce reliably locally or with try pushes (especially with MacOS... since I could not focus on `#downloadsHistory`).  So instead, I opted for another solution: removing the [`!openedManually`](https://searchfox.org/mozilla-central/source/browser/components/downloads/content/downloads.js#657,659) condition and testing this change locally on Ubuntu. Made a [try push](https://treeherder.mozilla.org/jobs?repo=try&revision=2a468289a0f9614a4a0d75fa1b6796ee99888762) with this change and also recorded how it behaves.

Given the following conditions:
1. downloads panel is empty
2. delay timer ends (in the video, `security.dialog_enable_delay` is set to 5 seconds)

... we end up focusing on the `#downloadsHistory` button. In `browser_documentnavigation.js`, we are supposed to be focused on [the url bar](https://searchfox.org/mozilla-central/source/browser/base/content/test/general/browser_documentnavigation.js#319-325). And, from there, we navigate backwards to the page's content using shift+F6. Before that can happen, the delay timer passes and we end up focusing on the downloads panel instead, messing up the order of focus.

I can think of two potential fixes:
1. addressing  flaky situation we found with bug 1747465
2. and/or simply setting `security.dialog_enable_delay` to 0 in the test `browser_documentnavigation.js`
Could not reproduce reliably locally or with try pushes (especially with MacOS... since I could not focus on `#downloadsHistory`).  So instead, I opted for another solution: removing the [`!openedManually`](https://searchfox.org/mozilla-central/source/browser/components/downloads/content/downloads.js#657,659) condition and testing this change locally on Ubuntu. Made a [try push](https://treeherder.mozilla.org/jobs?repo=try&revision=2a468289a0f9614a4a0d75fa1b6796ee99888762) with this change and also recorded how it behaves.

Given the following conditions:
1. downloads panel is empty
2. delay timer ends (in the video, `security.dialog_enable_delay` is set to 5 seconds)

... I'm suspecting that we end up focusing on the `#downloadsHistory` button. In `browser_documentnavigation.js`, we are supposed to be focused on [the url bar](https://searchfox.org/mozilla-central/source/browser/base/content/test/general/browser_documentnavigation.js#319-325). And, from there, we navigate backwards to the page's content using shift+F6. Before that can happen, the delay timer passes and we end up focusing on the downloads panel instead, messing up the order of focus.

I can think of two potential fixes:
1. addressing  flaky situation we found with bug 1747465
2. and/or simply setting `security.dialog_enable_delay` to 0 in the test `browser_documentnavigation.js`

Back to Bug 1747162 Comment 13