As a follow up for debugging. During editing, the addressbook `<html>` element has a `scrollHeight` that exceeds the viewport height. If you put `overflow: scroll` on the toplevel, to replace the `overflow: clip` (https://searchfox.org/comm-central/rev/88e1abf44865d212a266f2c8f295f2e64dcbf78d/mail/themes/shared/mail/messenger.css#18), then it makes it visible and you can scroll it as normal. But below the page content is just whitespace. So the problem appears to be: 1. The toplevel `<html>` under the `xul:browser` is assigned too much space when the edit form is displayed, resulting in a large `scrollHeight`. I've seen something similar with XUL layout not understanding the CSS grid layout, so maybe something similar is happening here. 2. Really, pressing Space shouldn't be scrolling `overflow: clip` because user and programmatic scrolling is meant to be prevented under this option. But since this is a toplevel element, maybe the usual styling rules to always be respected.
Bug 1776278 Comment 9 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
As a follow up for debugging. During editing, the addressbook `<html>` element has a `scrollHeight` that exceeds the viewport height. If you put `overflow: scroll` on the toplevel, to replace the `overflow: clip` (https://searchfox.org/comm-central/rev/88e1abf44865d212a266f2c8f295f2e64dcbf78d/mail/themes/shared/mail/messenger.css#18), then it makes it visible and you can scroll it as normal. But below the page content is just whitespace. So the problem appears to be: 1. The toplevel `<html>` under the `xul:browser` is assigned too much space when the edit form is displayed, resulting in a large `scrollHeight`. I've seen something similar with XUL layout not understanding the CSS grid layout, so maybe something similar is happening here. 2. Really, pressing Space shouldn't be scrolling `overflow: clip` because user and programmatic scrolling is meant to be prevented under this option. But since this is a toplevel element, maybe the usual styling rules to always be respected. 3. Pressing Space to activate a button shouldn't be propagating to the toplevel and used to scroll.
As a follow up for debugging. During editing, the addressbook `<html>` element has a `scrollHeight` that exceeds the viewport height. If you put `overflow: scroll` on the toplevel, to replace the `overflow: clip` (https://searchfox.org/comm-central/rev/88e1abf44865d212a266f2c8f295f2e64dcbf78d/mail/themes/shared/mail/messenger.css#18), then it makes it visible and you can scroll it as normal. But below the page content is just whitespace. So the problem appears to be: 1. The toplevel `<html>` under the `xul:browser` is assigned too much space when the edit form is displayed, resulting in a large `scrollHeight`. I've seen something similar with XUL layout not understanding the CSS grid layout, so maybe something similar is happening here. 2. Really, pressing Space shouldn't be scrolling `overflow: clip` because user and programmatic scrolling is meant to be prevented under this option. But since this is a toplevel element, the usual styling rules aren't always respected. 3. Pressing Space to activate a button shouldn't be propagating to the toplevel and used to scroll.