Closed Bug 526292 Opened 15 years ago Closed 15 years ago

View-->Headers--All overfill all message pane preview

Categories

(Thunderbird :: Message Reader UI, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: Aureliano, Assigned: BenB)

References

Details

(Keywords: regression, Whiteboard: Fixed by patch in bug 525302)

STR: 1. enable message preview and set view-->headers-->Normal; 2. open a message in new window; 3. in standalone window, select view-->headers-->All; 4. close standalone window; 5. select another message (up or down) in message list: the new message select show all headers but headers pane overfill all message preview area. A workaround for this issue is to goto view-->headers and magical headers pane resize. It happens also in safe-mode. No errors in Errors Console.
Which build, i.e., before or after bug 489609 was checked in?
(In reply to comment #1) > Which build, i.e., before or after bug 489609 was checked in? Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.6pre) Gecko/20091103 Lightning/1.0pre Shredder/3.0pre ID:20091103032145
Yes, I see the same. It happens in the stand-alone window only, not if you just open the message in a new tab. Thus, while View > Headers equally applies to all windows, the show_header_mode attribute is apparently only reset for the current window in which the header view is changed. Unfortunately, this needs to block bug 489609 as a regression which will have to be fixed. :-(
Blocks: subjectwrap
Keywords: regression
OS: Windows XP → All
Hardware: x86 → All
Depends on: 525302
The patch in bug 525302 fixes this.
Assignee: nobody → ben.bucksch
Whiteboard: Fixed by patch in bug 525302
A particularly painful aspect of this bug is that restarting doesn't make the problem go away; the workaround is that the user has to turn off "Show All Headers" mode and turn it back on without the standalone window involvement. It does, however, appear to go away on Mac if a menu is opened that causes a submenu to open over the message header pane thereby forcing a repaint. Or something like that. I haven't yet been able to nail it down precisely. If we ship without taking this fix and without backing out bug 489609, we should probably relnote the workaround.
Bug 525302 checked in, on trunk and 3.0 branch. FIXED
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Version: 3.0 → Trunk
Verified fixed in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.6pre) Gecko/20091110 Shredder/3.0pre, no issues when changing header views in stand-alone windows. The "more" button now allows the scroll bar to appear as well again, so that works as intended too.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.