Closed Bug 840623 Opened 12 years ago Closed 9 years ago

When returning to a tab with a message, the view is reset to the beginning

Categories

(Thunderbird :: Toolbars and Tabs, defect)

17 Branch
x86
FreeBSD
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 487386

People

(Reporter: mi+mozilla, Unassigned)

Details

If I open a (long) message in a separate tab, scroll down in the tab, and then switch to another tab, both the message's body and the message's headers view will be reset to the very beginning (with the scroll at the very top), when I return to the message's tab. Rather inconvenient and unexpected -- firefox, for example, does not have this problem. Not sure, when this problem first appeared -- I noticed it with Thunderbird 14 and it remains a problem with 17.
I could see phenomenon in Tb 17.0.2 on Win-XP. (1) Tab-1 : Mbox-1, mail-1 is selected, virtical scroll bar is shown for mail Tab-2 : Mbox-2, mail-2 is selected, horizontal scroll bar is shown for mail (Mbox-2 can be same Mbox-1 of Tab-1) (2) At Tab-1, scroll to bottom (3) Switch to Tab-2, scroll to right most (4) Switch to Tab-1 => scroll position is top. Scroll to bottom. (5) Switch to Tab-2 => scroll position is left most. Scroll to right most. (6) Repeat (4)/(5) Scroll position is not saved? Or scroll position is not restored? > I noticed it with Thunderbird 14 If so, it may be already reported bug.
(In reply to WADA from comment #1) > ... > Scroll position is not saved? Or scroll position is not restored? > > > I noticed it with Thunderbird 14 > > If so, it may be already reported bug. Mikhail ?
Flags: needinfo?(mi+mozilla)
Priority: P4 → --
(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #2) > (In reply to WADA from comment #1) > > ... > > Scroll position is not saved? Or scroll position is not restored? I do not know, what is happening. A GUI-developer should be able to figure it out in a few minutes, though. > > > I noticed it with Thunderbird 14 > > > > If so, it may be already reported bug. > > Mikhail ? Sorry, what is the question? Whether or not this was reported earlier? I don't know -- I could not find an earlier complain about the same problem, but, maybe, it was simply worded differently. The problem is certainly still here -- in TB 38.4.0, at least.
pretty sure this is duplicate
Status: NEW → UNCONFIRMED
Ever confirmed: false
Flags: needinfo?(mi+mozilla)
Whiteboard: [dupme]
(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #4) > pretty sure this is duplicate Would not you want to find a duplicate BEFORE making such a statement -- and changing the status to "UNCONFIRMED"? Especially, if the actual confirmation from another user is right here on the ticket?
because I didn't have to to search, and making it unconfirmed helps ensure someone/anyone will look for the duplicate
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Whiteboard: [dupme]
You need to log in before you can comment on or make changes to this bug.