1722331 - Text content of work address fields overlaps `Get Map` button on AB card preview, involving disproportionate column width layout with slightly longer field entry in 1st column content (esp. Notes)

Status: RESOLVED FIXED

(Thunderbird :: Address Book, defect)

Description

[Thomas D. (:thomas8)]

+++ This bug was initially created as a clone of Bug #1722296 +++

This is a regression which routinely messes up the preview of a contact in AB as soon as there's a bit more of text e.g. in the Notes field (Other section) and any address information on the Work section.

STR

91.0b3 (64-bit) / 92.0a1 (2021-07-26) (64-bit)

1. In Beta or Daily, create a new contact using exactly the details below (important!)
2. Select the contact and look at the work address with Get Map button in the preview pane.

Contact section

• First name: John
• Last name: Doe
• Display name: (generated)
• Email: [e-mail]

Work section

• City: Athens
• Country: Greece

Other section

• Notes:

Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.

Actual results:

(see screenshot)

• Contact Preview: 1st column is disproportionately wide, which needlessly
  • squeezes 2nd column
  • pushes 2nd column out of view, causing horizontal scrollbar
• Get Map button on AB card preview gets overlaid by text content of Work address fields

Expected results:

• Field content should never overlap buttons
• Keep a sane with ratio between 1st and 2nd column to avoid disproportionate, distorted layout and needless horizontal scrollbar

Comment 1

[Thomas D. (:thomas8)]

Sorry, this bug was submitted prematurely - will update comment 0

Comment 2

[Thomas D. (:thomas8)]

Summary of comment 0 has been updated.

Comment 3

[Thomas D. (:thomas8)]

Attachment: Screenshot 1: Actual result of comment 0 - disproportionate and distorted layout

Here's a screenshot of Actual result of comment 0 on 91.0b3 (64-bit), Win10.

Comment 4

[Thomas D. (:thomas8)]

Attachment: Screenshot 2: Real-life example of actual result

Here's a real-life example from Bug 1722296 where this was first reported.
Even with a pretty wide Thunderbird window, 2nd column still squeezed and distorted.

Comment 5

[Alice0775 White]

Regression window:
https://hg.mozilla.org/comm-central/pushloghtml?fromchange=a4dbc88b7f17f1fce1b049873da709cfeb316b03&tochange=aeddd048e791b84f80ca8478598ee30aa960a7db
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b740f950e4971e9e17c16b0e19e569cd3b07ceb5&tochange=83a21ab93aff939d348468e69249a3a33ccfca88

Comment 6

[Thomas D. (:thomas8)]

Awesome, thanks Alice!

Yes, this was probably regressed by https://phabricator.services.mozilla.com/D111076 from bug 1683303.

Henry, could you have a look?

Comment 7

[Thomas D. (:thomas8)]

Attachment: Screenshot 3: Comparing preview layout of TB 78 vs. TB 91/92

Here's before and after regression.
Placing the Get Map button below the last address field would prevent the overlap.

Comment 8

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

I think its the min-width on the .cardViewGroup and .cardViewText (see in https://searchfox.org/comm-central/source/mail/themes/shared/mail/addressbook.css) that's causing the overflow, and the overflow is not hidden. I'm not sure why no overflow was set before, since you get the same problems before I removed the equalsize attribute if any of the descriptions are long.

The min-width value makes sure an element is given at least some width, but it also allows the element to be shrunk to that width if the natural width is larger than the min-width. So, if you want to keep the min-width values so that things don't get too wide, you should probably make them bigger (>100px) since the current 30px is not much, especially with the "Get Map" button. And you should set

overflow: hidden;
/* optional */
text-overflow: ellipsis;

probably for .cardViewLink as well.

Putting "Get Map" below might look better as well.

I'm not sure if this is strictly a regression by 9b2de929a378, since the this could happen before (set the display name to "loooooooooooooooooooong" and shrink the window), but I suppose it is easier to see without equalsize.

Comment 9

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

Hmm, doing some testing, you might need to change the display to inline for the description elements, because the overflow: hidden causes the long notes to be cropped vertically (some xul -moz-box effect). And you might want to set the max-width of the columns, or you could use a flex display if you want something more fancy.

Comment 10

[Magnus Melin [:mkmelin]]

Might be best to back out the regressing patch from the 91 branch, and not worry about trunk where the old address book front-end code will be removed probably in the next months.

Comment 11

[Magnus Melin [:mkmelin]]

Rob, please back out https://hg.mozilla.org/comm-central/rev/9b2de929a378 from beta (91)

Comment 12

[Rob Lemley [:rjl]]

Backout: Bug 1683303 comment 23.

Comment 13

[Magnus Melin [:mkmelin]]

Ok let's close this then. We won't be fixing it for trunk.