478592 - Message header contact jumps away to next row on right-clicking or tab-focus, can't open context menu

Status: RESOLVED WORKSFORME

(Thunderbird :: Message Reader UI, defect)

Description

[Thomas D. (:thomas8)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090213 Shredder/3.0b2pre

In message reader's header display, when (display) contacts happen to fill available space to the right very tightly, right-clicking on the last contact in a given row will cause that contact to jump to the next row, and context menu doesn't open.


Reproducible: Always

Steps to Reproduce:
1. Message reader / message header pane: Make sure last display contact in the first row of multiple contacts is at the right edge of screen (adjust TB window border manually so that the last address just fits without being moved to the next row)
2. right-click on last contact in first row
3.
Actual Results:  
Last contact of row 1 jumps into row 2, context menu doesn't pop up (likely because mouse-up event fires on empty space in the first row).

Expected Results:  
Contacts should never move, let alone jump away just because I click on them!

The obvious cause for this is that when right-clicking on a contact, it gets dotted focus indicator which makes the contact's area one or two pixels wider (look closely at any given contact and see how it moves a bit to the right when you click on it). The focussed thus wider contact doesn't fit any more in first row, it moves to next row, and consequently context menu fails to open.

Due to Bug 470472 (Message Reader: Left-Clicking on contact doesn't move focus indicator (double focus)), this currently only occurs when right-clicking, but when bug 470472 gets fixed, the same will happen for left-clicks as well.

Like it or not (cf. Bug 460647, comment #8), but imho one day someone will have to arrange dotted focus indicator in a way that does no longer cause contacts to move in any direction, not even a single pixel.

Comment 1

[Thomas D. (:thomas8)]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b5pre) Gecko/20090508 Shredder/3.0b3pre

This bug is still present in current nightly, and should be confirmed (NEW). Steps are easy to reproduce with any given email that has more than one contact in the respective headers (simply adjust your TB window size to create the scenario). This bug also occurs when user just tabs through the contacts - when focus gets to the last contact in first display row, that contact becomes ca. 1 pixel wider due to dotted focus indicator, and contact jumps out of sight. I don't reckon jumping contacts are expected behaviour.

Comment 2

[Ludovic Hirlimann [:Usul]]

confirming with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b5pre) Gecko/20090508 Shredder/3.0b3pre - thanks for pinging the bug Thomas.

Comment 3

[Wayne Mery (:wsmwk)]

does this relate to bug 655543?

Comment 4

[Thomas D. (:thomas8)]

(In reply to comment #3)
> does this relate to bug 655543?
From the description of bug 655543, I think there is no relationship.

This bug is about a stylesheet problem where a transparent 1px border needs to be added to any contact in header bar so that contacts retain same width even when they get focus (where a dotted 1px border will be added, currently increasing the width and causing contacts to jump to next row in "edge cases" (pun intended)).

The other bug 655543 is about a change of layout that occurs through "all headers" view and indents everything to the right (because of longer header-titles in a tabular structure), resulting in from-header being covered by buttons (or not, as some folks say it's now wfm).

Comment 5

[Jim Porter (:squib)]

I don't see this, and anyway the border is always present (at least nowadays it is); it's just transparent when it's not focused, so there should be no size change.

Comment 6

[Thomas D. (:thomas8)]

Jim, thanks for looking into this, and indeed I cannot seem to reproduce the behaviour described in comment 0 any more. -> wfm