The problem I'm trying to solve: There is currently no way to create a selected region in the screenshots overlay with the keyboard.
I recently added support for resizing a selected region in bug 1801954, but a user still needs to create a region with the mouse before the keyboard can be used.
I tried to look at what other browsers are doing in this scenario. Unfortunately there isn't much to go off. Most browsers, I can't even take a screenshot and the only browser that I found to have keyboard support for screenshots is MS Edge. In Edge, when you open screenshots, if your mouse isn't over the content area it will immediately move your mouse to the center of the page. If your mouse is over the content, it remains in place. Then, arrow keys will move the cursor around and you can hit space/enter to start creating a region.
I didn't like that Edge moved the mouse immediately after opening screenshots so I took a different approach.
My approach:
Screenshots will not move the mouse until an arrow key is pressed.
How it works:
If your cursor is above the content and an arrow key is pressed, the cursor will move in the direction of the arrow key that was pressed.
If your cursor is not above the content and a arrow key is pressed, the cursor will be moved to the middle of the content. Screenshots will not move the cursor until an arrow key is pressed.
When moving around the overlay with the keyboard: only hitting an arrow key will move the cursor around by 1px. If shift + arrow key, the cursor will move around by 10px.
When space is clicked while moving the cursor, it will start a region. Moving the arrow keys allows the region to sized.
When the cursor is above an element and the hover element rect is visible, hitting enter will select that region. If no hover element region exists, enter will behave the same as space.
I am also keeping the screenshots UI focused in this patch. Tab/shift + tab will keep focus to screenshots UI. Shift + F6 will escape the focus loop I've made in this patch if needed. Although, if a user has entered screenshots, it makes sense that for the current time, only screenshots UI is focusable.
Differential Revision: https://phabricator.services.mozilla.com/D197703
The problem I'm trying to solve: There is currently no way to create a selected region in the screenshots overlay with the keyboard.
I recently added support for resizing a selected region in bug 1801954, but a user still needs to create a region with the mouse before the keyboard can be used.
I tried to look at what other browsers are doing in this scenario. Unfortunately there isn't much to go off. Most browsers, I can't even take a screenshot and the only browser that I found to have keyboard support for screenshots is MS Edge. In Edge, when you open screenshots, if your mouse isn't over the content area it will immediately move your mouse to the center of the page. If your mouse is over the content, it remains in place. Then, arrow keys will move the cursor around and you can hit space/enter to start creating a region.
I didn't like that Edge moved the mouse immediately after opening screenshots so I took a different approach.
My approach:
Screenshots will not move the mouse until an arrow key is pressed.
How it works:
If your cursor is above the content and an arrow key is pressed, the cursor will move in the direction of the arrow key that was pressed.
If your cursor is not above the content and a arrow key is pressed, the cursor will be moved to the middle of the content. Screenshots will not move the cursor until an arrow key is pressed.
When moving around the overlay with the keyboard: only hitting an arrow key will move the cursor around by 1px. If shift + arrow key, the cursor will move around by 10px.
When space is clicked while moving the cursor, it will start a region. Moving the arrow keys allows the region to sized.
When the cursor is above an element and the hover element rect is visible, hitting enter will select that region. If no hover element region exists, enter will behave the same as space.
I am also keeping the screenshots UI focused in this patch. Tab/shift + tab will keep focus to screenshots UI. Shift + F6 will escape the focus loop I've made in this patch if needed. Although, if a user has entered screenshots, it makes sense that for the current time, only screenshots UI is focusable.
Differential Revision: https://phabricator.services.mozilla.com/D197703
* Flip the component pref to true by default for nightly builds only
* Move the pref check and initialization to a startup idle task
* And be a bit smarter about when we get and disable the addon
* Fix a bug where we try to communicate with the overlay after the window actor is destroyed when
the component pref gets flipped off during use
Differential Revision: https://phabricator.services.mozilla.com/D196888
* Flip the component pref to true by default for nightly builds only
* Move the pref check and initialization to a startup idle task
* And be a bit smarter about when we get and disable the addon
* Fix a bug where we try to communicate with the overlay after the window actor is destroyed when
the component pref gets flipped off during use
Differential Revision: https://phabricator.services.mozilla.com/D196888
* Flip the component pref to true by default for nightly builds only
* Move the pref check and initialization to a startup idle task
* And be a bit smarter about when we get and disable the addon
* Fix a bug where we try to communicate with the overlay after the window actor is destroyed when
the component pref gets flipped off during use
Differential Revision: https://phabricator.services.mozilla.com/D196888
* Flip the component pref to true by default for nightly builds only
* Move the pref check and initialization to a startup idle task
* And be a bit smarter about when we get and disable the addon
* Fix a bug where we try to communicate with the overlay after the window actor is destroyed when
the component pref gets flipped off during use
Differential Revision: https://phabricator.services.mozilla.com/D196888
Both the extension and the component were both passing in numbers like 286.6499938964844 but they were behind rounded differently or something?
It seems to me that the extension was flooring the numbers somewhere and the component wasn't flooring or rounding the numbers anywhere.
The two images would start off being the same but then would progressively become more different. See image diff below
{F5955989}
If we round the region before drawing the snapshot the resulting images will match.
Sometimes there is some offset difference (only 1 px difference) because the component now `round`s and I think the extensions `floor`s. `286.6499938964844` would be `286` for the extension and `287` for the component.
Differential Revision: https://phabricator.services.mozilla.com/D199059
* Move the chrome panel buttons into a `box` which is inserted into #navigator-toolbox
* Adjust what open/closed means using hidden instead
* Capture a weak ref to the focused element on open, and attempt to put focus back on exit
* Add some restore-focus tests
* Fix a bug where cancel via overlay "X" button wasn't exiting properly
* Place initial focus in the preview dialog button on the download button
Differential Revision: https://phabricator.services.mozilla.com/D181184
