1776278 - Typing into multiline contact fields scrolls to top of contact edit area, sometimes breaks layout completely

Status: RESOLVED FIXED

(Thunderbird :: Address Book, defect)

Description

[[e-mail]]

When you input into a multiline contact field, the field is scrolled to the top of the contact edit area. (Sometimes the layout breaks completely but I wasn't able to reproduce this reliably.) This appears to be because scrollIntoView is used with its default behaviour of scrolling to the top. Perhaps you wanted to use scrollIntoView({ block: "nearest" })?

Comment 1

[Thomas D. (:thomas8)]

Thanks Neil!
However, this worksforme on 102.0b8 (64-bit), Win10 - just scrolls the input area into view, but not to top, and no layout breakage at all.

Please provide more detail:

• exact TB version
• your OS
• Does this happen with ≡ > Help > Troubleshoot Mode…?
• STR
• Screenshots/Screencast of actual result

Comment 2

[[e-mail]]

Attachment: Screen shot

I found some repeatable steps for the layout bustage:

1. Click New Contact
2. Click all of the ⊕ options (Add web site... Add organisational properties)
3. Enter data into the Street, Notes and Organisation fields

Thunderbird 102.0b8 (32-bit), Windows 10. Problem also occurs in troubleshooting mode.

Comment 3

[u695164]

I can confirm this issue on Thunderbird Daily 64bit, Windows 10.

I'm currently unable to tell what the exact threshold is. But it seems that there is a threshold when the scroll able content in the edit view is greater than a certain height problems with focus appear on input/textarea/selects.
This problem is mostly prominent by typing in a textarea. But it also happened to me by activating a button with the space key (with enter this problem doesn't occur).

Display resolution height 1050
<div class="contact-header">[...] 100px height
<vcard-edit>[...] 1122.27px height

The issue is not present

With the same numbers besides
<vcard-edit>[...] 1137.97 height
the error occurs.

Comment 4

[u695164]

I could also reproduce this issue on linux64.

The html tag in the xul:browser element with the id addressBookTabBrowser0 is behaving weird.
A temporary fix could be to position the body tag absolute in the addressBookTabBrowser0 element. But I'm pretty sure that this is not a fix for the real issue.

Comment 5

[u695164]

Attachment: Bug 1776278 - Surpress scrolling of the Address Book html tag. r=aleca

By pressing space to activate a button or typing in a textarea with a high enough height in the edit contact
the html element escaped the box of the parent. With a position: fixed; this behaviour is supressed.

Comment 6

[Henry Wilkes (they/them) [:henry-x]]

Space, and Shift+Space cause the about:addressbook Window to scroll. This is the default response to keydown when Space is pressed in a page, but it shouldn't trigger when focusing a button. But it only seems to be effecting the buttons in the <form> element, which is strange.

If we can't find the origin and fix it, then I think the better response would be to prevent the #addressBookTabBrowser content window from scrolling, or restore scrollY to 0 whenever it changes.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/bdc6aef06066
Surpress scrolling of the Address Book html tag. r=aleca

Comment 8

[Henry Wilkes (they/them) [:henry-x]]

I can still get the strange scroll behaviour when pressing Space on the Cancel or Save buttons when editing an existing contact. The Cancel one is easier to see when the dialog pops up. Strangely, I don't get it for the Delete button, and I don't get it when filling out the form for a new contact. Maybe that is a hint as to the origin. Seems like a mozilla-central issue.

We might need another Event.preventDefault for these two buttons (or their container). However, given the only solutions we have is hacks right now, it might be better to choose a solution that keeps the hacks small and in one place. So overall, maybe we should stick to the original CSS hack

body { position: fixed; }

or if we prefer javascript, use

abDocument.addEventListener("scroll", () => { abWindow.scrollTo({ top: 0 }); });

as a smaller, more general patch whilst the exact cause remains unknown.

Comment 9

[Henry Wilkes (they/them) [:henry-x]]

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.

Comment 10

[u695164]

As by henry described the issue is happening when using Space or Shift + Space on the buttons Cancel or Save.
Shall we prevent the behaviour on the buttons or use a band aid fix for this behaviour?

Comment 11

[Alessandro Castellani [:aleca]]

Pressing Space to activate a button shouldn't be propagating to the toplevel and used to scroll.

I would suggest preventing the event propagation on Space keypress for those buttons, and avoid hijacking the document scroll event or other things.

We could also experiment with wrapping the whole area around a parent DIV in order to not style the body as a CSS grid. I'm not sure if that would do anything.

Comment 12

[Henry Wilkes (they/them) [:henry-x]]

re-opening for the "Cancel" and "Save" buttons (comment 8)

Comment 13

[u695164]

Attachment: Bug 1776278 - Surpress Address Book html scrolling on save and cancel. r=aleca

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/9b4bfa71b01f
Surpress Address Book html scrolling on save and cancel. r=aleca

Comment 15

[u695164]

Comment on attachment 9283370 [details]
Bug 1776278 - Surpress scrolling of the Address Book html tag. r=aleca

[Approval Request Comment]
Regression caused by (bug #):
User impact if declined: When pressing space on a button in the edit of a contact the layout breaks if there are a more elements in the edit view.
Testing completed (on c-c, etc.): on c-c
Risk to taking this patch (and alternatives if risky): Low

Comment 16

[u695164]

Comment on attachment 9287260 [details]
Bug 1776278 - Surpress Address Book html scrolling on save and cancel. r=aleca

[Approval Request Comment]
Regression caused by (bug #):
User impact if declined: When pressing space on the cancel or save button in the edit of a contact the layout breaks if there are a more elements in the edit view.
Testing completed (on c-c, etc.): on c-c
Risk to taking this patch (and alternatives if risky): Low

Comment 17

[Wayne Mery (:wsmwk)]

Comment on attachment 9283370 [details]
Bug 1776278 - Surpress scrolling of the Address Book html tag. r=aleca

[Triage Comment]
Approved for beta

Comment 18

[Wayne Mery (:wsmwk)]

Comment on attachment 9287260 [details]
Bug 1776278 - Surpress Address Book html scrolling on save and cancel. r=aleca

[Triage Comment]
Approved for beta

Comment 19

[Wayne Mery (:wsmwk)]

Comment on attachment 9283370 [details]
Bug 1776278 - Surpress scrolling of the Address Book html tag. r=aleca

(already on beta)

[Triage Comment]
Approved for esr102

Comment 20

[Wayne Mery (:wsmwk)]

Comment on attachment 9287260 [details]
Bug 1776278 - Surpress Address Book html scrolling on save and cancel. r=aleca

(already on beta)

[Triage Comment]
Approved for esr102

Comment 21

[Rob Lemley [:rjl]]

Thunderbird 102.2.0:
https://hg.mozilla.org/releases/comm-esr102/rev/ba954031a1b0
https://hg.mozilla.org/releases/comm-esr102/rev/033930b07c83