Closed Bug 487386 Opened 15 years ago Closed 7 months ago

Tabs don't maintain exactly what was shown when switching tabs (e.g. reload feed page, loss of message scroll position, text selection, focus, attachment pane UI state) [not remember, lose, forget, reset] - current status: see comment 99

Categories

(Thunderbird :: Toolbars and Tabs, defect)

defect
Not set
critical

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: yaoziyuan, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug, )

Details

(Keywords: polish, Whiteboard: [closeme 2023-08-11][ux-papercut][duptome][gs][UXprio][tb-papercut][will be fixed by bug 1729379 and friends, WIP])

Attachments

(2 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.8) Gecko/2009033100 Ubuntu/9.04 (jaunty) Firefox/3.0.8 GTB5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b4pre) Gecko/20090406 Shredder/3.0b3pre

i use thunderbird 3 with tor. if i open a rss news item (html format) in a new tab, and wait until the web page is loaded, and then switch away to another tab, and then switch back to this tab, the tab's html view will be blank and i have to wait 30 seconds (i guess this time is used to communicate with the server to check if thunderbird's cached web page is the same version as the server's), and then the cached web page suddenly show up completely (i guess thunderbird has been informed by the server that its cached version is up-to-date).

i'm annoyed by this 30-second communication. i want thunderbird tabs to behave like firefox tabs, i.e. a tab that is previously loaded can immediately show its content (web page) when i switch to it. no online communication is needed.

Reproducible: Always

Steps to Reproduce:
see above, "Details".
Actual Results:  
see above, "Details".

Expected Results:  
see above, "Details".
Yup, this is rather annoying... destroys much of what makes tabs useful.
Status: UNCONFIRMED → NEW
Component: Mail Window Front End → Toolbars and Tabs
Ever confirmed: true
Flags: blocking-thunderbird3?
OS: Linux → All
QA Contact: front-end → toolbars-tabs
Hardware: x86 → All
Summary: cached web pages in tabs don't show up immediately → tabs don't maintain exactly what was shown when switching tabs (e.g. reload feed page)
So the issue here is that rather than have separate message display (xul) elements for each tab, we actually just collapse parts of the 3-pane display and leave the message pane in place.

Hence when we change tabs, we need to reload the messages/displays into the appropriate tabs.

You'd certainly need the content policy fix in bug 374578 to fix this. You'd then have to fix mailTabType.message to have its own UI elements, and behave correctly - so ensure we get the right menu items enabled/disabled etc.
Depends on: 374578
whatever this fix may entail, it's the right direction and worth even architectural changes.
how painful is this when not using tor?  I haven't noticed huge delays, so I'm going to assume that the delays are primarily due to the lack of caching.  As such, denying blocking.  Someone will jump in if I'm way off.
Flags: blocking-thunderbird3? → blocking-thunderbird3-
At least for me the main problem isn't perhaps with the actual delay of loading. More that it's actually loading anything again, *at all*. And by "loading" i mean anything that's not keeping all UI elements exactly as they were when I left the tab.
Flags: wanted-thunderbird3?
(In reply to comment #5)
> how painful is this when not using tor?  I haven't noticed huge delays, so I'm
> going to assume that the delays are primarily due to the lack of caching.  As
> such, denying blocking.  Someone will jump in if I'm way off.

So I notice this occasionally, as I now start to have a habit of opening feeds in new tabs after which I switch back to my inbox - especially after having a slow net connection, e.g. in public wifi.

The tab loads again when I switch back to it, causing me to wait again, when it should have been loaded and cached somewhere. As mkmelin mentions, this issues obstructs part of what makes tabs useful, which is loading things in the background while temporarily back in the inbox.

I don't know if caching support will fix this, nor the best way forward. No tor needed, just a slow net connection, and possibly a slow(er) computer, e.g. a netbook? :)

Renominating blocking, cc'ing clarkbw as I'm quite sure this is tabs' user experience-fodder.
Flags: blocking-thunderbird3- → blocking-thunderbird3?
Version: unspecified → Trunk
Note that even if this is very quick, having to scroll again is painful.
In the long term this requires the fully non-multiplexed tabs, which we don't have time to deal with in tb3.  Andrew, is there a bug for that?

There may be some smaller partial fixes that we can do, however.  

As is, I don't think this bug can block.
Flags: blocking-thunderbird3? → blocking-thunderbird3-
(In reply to comment #10)
> In the long term this requires the fully non-multiplexed tabs, which we don't
> have time to deal with in tb3.  Andrew, is there a bug for that?

bug 497348 suggests a workaround, which IMO must block+ for TB3.  Unsure whether RSS needs to be specialized case.
Summary: tabs don't maintain exactly what was shown when switching tabs (e.g. reload feed page) → tabs don't maintain exactly what was shown when switching tabs (e.g. reload feed page, scroll position)
We should definitely be looking at a fix for this into the 3.1 time frame.  However I thought we already had a bug filed on that.
(In reply to comment #6)
> At least for me the main problem isn't perhaps with the actual delay of
> loading. More that it's actually loading anything again, *at all*. And by
> "loading" i mean anything that's not keeping all UI elements exactly as they
> were when I left the tab.

I have to concur with this assessment: If I have separate emails open in separate tabs, intending to read back and forth between them, it is much less than helpful if I have to scroll to find my place again once I return to the tab. I expect the content of the tab to remain unchanged unless/until I act on it.

Using TB3 RC1 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091121 Lightning/1.0b1pre Thunderbird/3.0)
just an idea: every time the user opens a message in a new tab, thunderbird actually opens a new tab and a new window. the message is loaded into the new window, as if it was "Open Message in New Window". the window doesn't have a window frame, a menubar, any toolbar or a status bar, and is repositioned to look as if it is inside the tab. needless to say it is always repositioned when the main window or the tab moves or resizes. when the user switches to another tab, the window is hidden.
Since I'm not using TOR, the timing is not a problem for me.  However, when I'm in the middle of reading a 500+ line newsgroup message and temporarily select a different tab, scrolling back to the top when I return to that long message is unacceptable.  This is not how tabbed browsing works, and it should not be how tabbed mail/news works.
Whiteboard: [duptome]
(In reply to comment #18)
> Since I'm not using TOR, the timing is not a problem for me.  However, when I'm
> in the middle of reading a 500+ line newsgroup message and temporarily select a
> different tab, scrolling back to the top when I return to that long message is
> unacceptable.  This is not how tabbed browsing works, and it should not be how
> tabbed mail/news works.

+1! The following has been taken from the "What's New" in TB3:
"If you like Firefox’s tabbed browsing, you’re going to love tabbed email."

Dear TB3 Team: I hate the way the tabs work in TB3. Firefox does not implement its tabs the same way! I can't even imagine to start scrolling in FF like crazy every time I return to the same web page to resume my reading position...

TB3's implementation of tabs works for short messages only. It's completely useless for anything with a scroll bar. Please fix this anomaly or get rid of tabs until they begin to work as advertised.

Regards
At least I now know why the tab system is so horrible in TB3 and why it is taking so long to fix it...

In most situations, it is a horrible idea to reimplement existing features.  Quite frankly, TB3's tabs are junk compared to any current tabbed browser I've seen.  And even if you magically get your version working just like the original, what are you going to do when the original starts to improve?  This just annoys the users and makes more trouble for the developers.  The developers should get to focus on making Thunderbird as great as possible, not having to waste time trying to fix (comparatively) hacked-together features.
Josh, while it's entirely reasonable to be frustrated by aspects of Thunderbird, Bugzilla is a venue specifically for driving the technical aspects of bugs forward.  If you feel the need to advocate or vent, <http://getsatisfaction.com/mozilla_messaging/topics/> is a more suitable place for that.  Please review <https://bugzilla.mozilla.org/page.cgi?id=etiquette.html> before your next comment in Bugzilla so that you have a better understanding of what is and isn't appropriate here.  Thanks!
Flags: wanted-thunderbird3? → wanted-thunderbird+
Whiteboard: [duptome] → [duptome] [gs]
Whiteboard: [duptome] [gs] → [duptome] [gs][UXprio]
There is a workaround I noticed with Thunderbird 5.0.  Use the conversations add-on.
Two more annyoing aspects of this general problem:

A) Undesired UI state changes of attachment pane

STR
1) view a msg with multiple attachments in a tab
2) show attachment pane (by clicking anywhere on attachment header bar, after landing of Bug 680695, Comment 19); reflect upon the need for bug 647036
3) Ctrl+click-select 2 out of X attachments
4) Ctrl+Tab, then Ctrl+Shift+Tab to switch forth and back to current tab

Actual result
a) attachment pane collapsed (needs extra click to show the pane again)
b) focus on attachment pane is lost (for keyboard users, need to re-focus)
c) attachment selection is lost (need to re-select attachments)

Expected result
*maintain UI state of current tab exactly as before switching tabs*
a) keep current attachment pane state (hidden vs. shown, here: shown)
b) keep focus whereever it is (in the attachment pane)
c) keep attachment selection (2 currently selected attachments)

Fixing this aspect might need to be coordinated with bug 647036.
---------------------------------------

B) undesired loss of text selection

STR

1) view a msg with multiple attachments in a tab
2) [scroll down and] select some text (e.g. a paragraph from the msg)
4) Ctrl+Tab, then Ctrl+Shift+Tab to switch forth and back to current tab

Actual result
- text selection is lost [and scroll position, too]

Expected result
- text selection is preserved [and scroll position, too]

Firefox has the correct behaviour.

Adjusting summary to include those 2 aspects and improve retrievability of this bug to avoid more duplicates.
Summary: tabs don't maintain exactly what was shown when switching tabs (e.g. reload feed page, scroll position) → tabs don't maintain exactly what was shown when switching tabs (e.g. reload feed page, loss of scroll position, text selection, focus, attachment pane UI state) [not remember, lose, forget, unwanted display refresh changes]
Whiteboard: [duptome] [gs][UXprio] → [duptome][gs][UXprio]
Summary: tabs don't maintain exactly what was shown when switching tabs (e.g. reload feed page, loss of scroll position, text selection, focus, attachment pane UI state) [not remember, lose, forget, unwanted display refresh changes] → tabs don't maintain exactly what was shown when switching tabs (e.g. reload feed page, loss of scroll position, text selection, focus, attachment pane UI state) [not remember, lose, forget, unwanted display refresh changes, reset]
Updating GS URL according to conventions.
Canonical GS report seems to be http://gsfn.us/t/1c54y.
I don't use Tor but definitely expect scroll position to be maintained in non-current tabs.  See comments 6, 16, 18, and 23 above.  
Is it possible for each "tab" object to store information about its scroll position?  That's at least one major improvement step.
How many dupes (currently 22) are needed before the Thunderbird team decides to put this bug at the top of their TODO list? :)
(In reply to Frédéric Buclin from comment #43)
> How many dupes (currently 22) are needed before the Thunderbird team decides
> to put this bug at the top of their TODO list? :)

Perhaps the problem is that they do not even HAVE a TODO list for *BUGS*?
Has anyone ever heard of such a thing, or seen it anywhere?
Meanwhile, they are busy rolling in cool new features like bigfiles & IM (never mind the collateral damage of some more bugs)...

But who knows, it might be a big strategy: Add big features to attract big crowds; wait until the big crowds start big screaming about big bugs; hence, finally convince Mother Mozilla that TB needs more staff to fix big bugs big time. You never know, it might work, and they might live happily everafter...
Just upgraded and they mentioned improving tab functionality.  I thought "wow, maybe they fixed that bug that has been keeping me from using them for the past several years."  Nope, still using windows, cause tabs are broken.
(In reply to WBT from comment #40)
> I don't use Tor but definitely expect scroll position to be maintained in
> non-current tabs.  See comments 6, 16, 18, and 23 above.  
> Is it possible for each "tab" object to store information about its scroll
> position?  That's at least one major improvement step.

I second this, please make tabs maintain the current scrolled position at least, this would wave a lot of concern from this PR.
I can't speak to the scroll position in tabs because I don't use them. I find them completely useless in fact, since opening or composing a message doesn't happen in a tab (why not?) it happens in a separate window instead. For those of us who loved Eudora, we're still waiting for a way to view EVERYTHING in tabs and no separate windows. Then we wouldn't need the message preview pane either. Oh well. RIP Eudora.
tubesing: If you don't use tabs, I'm curious why you're interested in this bug? In any case: Tools > Options > Advanced > Reading & Display > Open messages in: A new tab. If you don't like the Preview pane, just slide it away, and start opening messages in tabs. 
I never see seperate windows myself, unless to write a new email. 

As for the scrolled position: this is also the main point for me. I often leave small todos in an email, and it's nice to have that in a tab that I can refer to. In the meanwhile I may of course receive other email, and then it's quite annoying if I have to scroll every time I want to check back in that 'todo email'.
Whiteboard: [duptome][gs][UXprio] → [ux-papercut][duptome][gs][UXprio]
Whiteboard: [ux-papercut][duptome][gs][UXprio] → [ux-papercut][duptome][gs][UXprio][tb-papercut]
Attached patch remember scoll for tabs v1 (obsolete) — Splinter Review
Slightly inspired by patch in:
https://bugzilla.mozilla.org/show_bug.cgi?id=541876
Works for messages, HTML messages and news messages. Doesn't work for RSS feeds (not sure why yet, any hint?). Remembers scrollX and scrollY and restores them when message is fully loaded.

Mark, I'm asking you for review because I don't know who else to address. Feel free to reassign review as you wish. Thanks.
Attachment #649653 - Flags: review?(mbanner)
Patch now remembers selection (text, elements) and attachment pane state (collapsed/expanded). Scroll doesn't work for RSS feeds yet.
Attachment #649653 - Attachment is obsolete: true
Attachment #649653 - Flags: review?(mbanner)
Attachment #650497 - Flags: review?(mbanner)
Comment on attachment 650497 [details] [diff] [review]
remember scoll for tabs v2

This doesn't feel like the correct way to fix this. As stated on tb-planning a week or so ago, remembering the scroll position is an awful hack, and like you've already picked up with RSS is likely to have lots of edge-cases. This makes me not keen on taking this solution, hence I'm giving this a feedback-.

I'll be posting a fuller description on the route I think we should take on tb-planning in the next few days, and hopefully from that discussion we'll get a plan for moving forward with this (which could be this route, or it could be something else).
Attachment #650497 - Flags: review?(mbanner) → feedback-
Depends on: 590910
This bug is again present in TB v.17.0.6 
0- main tab
1- Open another tab (first) with a msg in it, scroll to some position.
2- switch to main tab, return to first tab 
3- the scroll position is lost.

However if some text is selected and this text is present in first tab, the position shows the selected text.
I don't think it was ever fixed yet, was it? It's also still present in 22.0b1 in any case.
Correct. This bug is not marked as fixed, so there's no need to report that you still see it in a new release. When this bug gets marked as fixed, someone will tell you when you should expect to see the fix, and how to test the fix before it makes it to end-users. Until then, just assume the bug still there.
(In reply to Mark Banner (:standard8) from comment #56)
> A possible route to fixing this is now available here:
> 
> http://groups.google.com/group/tb-planning/browse_thread/thread/
> 4ef367cfbbcb19d6

further meat, which I am sure Mark's proposal takes into account, is asuth's excellent missive https://groups.google.com/d/msg/tb-planning/QiK2hTRxyBs/4MeW1V3l3yoJ in March 2012
(In reply to Mark Banner (:standard8) from comment #55)
> Comment on attachment 650497 [details] [diff] [review]
> remember scoll for tabs v2
> 
> This doesn't feel like the correct way to fix this. As stated on tb-planning
> a week or so ago, remembering the scroll position is an awful hack, and like
> you've already picked up with RSS is likely to have lots of edge-cases. This
> makes me not keen on taking this solution, hence I'm giving this a feedback-.

Any given method may not "feel like the correct way to fix this", and any given method very well may be "an awful hack", but don't you think we deserve SOME progress for this DESIGN FLAW which has been known for over six years?

If you really love your software, or care about your users, then PLEASE stop adding features until you fix the bugs that have been present for the past 35+ versions.

Seriously, don't you think 6+ years is long enough to wait to fix this design flaw?  How many times does it need to be reported as a bug before someone at Mozilla decides to do something about it?

I know the people who do this are volunteers, and I really am grateful to Mozilla for Firefox and Thunderbird, but it's completely unacceptable to leave design flaws and/or bugs untouched for over six years while continuing to add features and expand the code base.
Note in the bugzilla fields there are many bugs blocking this one, and looking further there are even bugs blocking those bugs. So there isn't the simple fix you imagine.  But the details are well laid out for anyone to contribute code.
Blocks: 541876
Summary: tabs don't maintain exactly what was shown when switching tabs (e.g. reload feed page, loss of scroll position, text selection, focus, attachment pane UI state) [not remember, lose, forget, unwanted display refresh changes, reset] → tabs don't maintain exactly what was shown when switching tabs (e.g. reload feed page, loss of message scroll position, text selection, focus, attachment pane UI state) [not remember, lose, forget, unwanted display refresh changes, reset]
Whiteboard: [ux-papercut][duptome][gs][UXprio][tb-papercut] → [ux-papercut][duptome][gs][UXprio][tb-papercut][blocked on bug 545666 and friends]
Depends on: 535373
(In reply to Wayne Mery (:wsmwk, NI for questions) from comment #64)
> Note in the bugzilla fields there are many bugs blocking this one, and
> looking further there are even bugs blocking those bugs. So there isn't the
> simple fix you imagine.  But the details are well laid out for anyone to
> contribute code.

And there's also a 116-line patch reported to fix most of this, which hasn't been applied for years because it "doesn't feel like the correct fix".

I agree it is not the ideal fix, but since no other fix has been proposed, I agree with Chris Cloutier. There should be a strong reason provided to reject it. This is not a fix for an obscure bug in an experimental branch. This (mostly) fixes a huge bug affecting every supported release which most users presumably experienced.

Quality management sometimes implies decisions you wish you wouldn't have to make. When you've marketed a badly broken feature and have been shipping such a bug for years, it may be best to take a non-ideal fix than to leave users fully exposed. Over 70 people have now requested a fix. Unless there is concern with the patch that it causes new significant issues, I certainly don't think the weight of 116 LOC-s alone should be a reason to postpone a fix by what unfortunately appears to be going to be several years otherwise.
I am experiencing buggy tab switching when using keyboard shortcuts (Ctrl+Page {Up,Down}).
If a tab is displaying a folder and I use Ctrl+Page Down to access the next tab, the message list is one page down when I come back to it (as if I had pressed Page Down alone).
If a tab is displaying a folder and I use Ctrl+Page Up to access the previous tab, the message list is one page up when I come back to it (as if I had pressed Page Up alone).
This happens on both Debian 8 and Windows 10.

While this ticket's title also covers this problem when broadly interpreted, I suppose this should be tracked in a different ticket? Has this been reported already?
Could this bug be focused a little bit more, please? This is a major bug that has been with us for 8 years and was reported by at least 30 different users (it has 29 duplicates) and it is voted to be the 5th most important. 

Is there any developer who cares about this bug? 

If a user runs into this bug then it is _very_ annoying. 

(Just imagine if you want to compare two longer emails and they scroll up to the top every the time you switch between them. If you highlight a line in order to go back easily then it doesn't work either, the selection disappears when you switch.)
Text selections, scroll positions, etc. are preserved if you open messages in new windows.

So a workaround is to not use tabs at all :/
(In reply to csongor from comment #69)
> Is there any developer who cares about this bug? 

I imagine most of the TB developers care about this bug; however, fixing it is a major effort. It would essentially require rewriting the message/folder views wholesale, and with all the other important issues that need fixing, I'm not surprised that no one has had the time to fix this.
Just a note: while there *is* a patch that fixes some of the issues here, I wouldn't be comfortable with landing it without thorough tests, since it's really just papering over the design issues here. I'd very much prefer to avoid landing untested hacks in Thunderbird if it can be helped.
Testing the patch should be easy enough for those who already build & run Thunderbird from source. "... if it can be helped": apparently, it can't for now! While having a proper fix/design is ideal, a dirty solution for now is better than an ideal solution 100 years later! And also, the dirty solution can be removed when a proper one is available. It's better to provide a fix for users rather than letting them suffer for years.
There currently aren't any automated tests and I certainly wouldn't r+ a patch like this without a thorough suite of automated tests to ensure that we don't randomly regress this feature (or other related ones). If someone produces a suite like that, it would help motivate landing this.

Nevertheless, if someone were interested in working on this, I'd rather see forward progress on fixing this properly, since that would solve the issue once and for all.
For its browser, SeaMonkey handles this situation and also closing the first, left-most tab (bug #485268).  Perhaps, the SeaMonkey code might be copied into Thunderbird.
No longer depends on: 537677

(In reply to Serhan Apaydın from comment #70)

Text selections, scroll positions, etc. are preserved if you open messages in new windows.
So a workaround is to not use tabs at all :/

The search in a standalone message window is also standalone.
While in the main window, we can search same things among different messages, without typing in each Find bar.
The two modes complement each other.

I dislike the precedent, but putting this at critical, as it meets the newly modified definition "Affecting a large number of users"

Severity: major → critical
Keywords: polish

We have 32 duplicates, the issue have been reported 11 years ago with severity critical. There are over hundred watchers and almost 80 votes to solve this but there's no priority set and the status is on "new". Should I interpret this as "P5"-Priority? Why OAuth2 authentication for Yandex is more important?
The tasks which this task depends on are updated 4 years ago, 2 years ago and 5 month ago.

This is an important bug. It just requires very significant changes.

Firefox maintains its tabs' vertical scroll button positions when switching between tabs. Any way to look at that code, and put it into Thunderbird?

This was marked as a duplicate of bug #1686556, but that's not accurate. In that other bug, I was saying that messages previously viewed in the current session, and later returned to, should retain their scroll position. This is orthogonal to tabs.

The two are at least related, but #1686556 is a problem that needs fixing even if Thunderbird didn't have tabs.

OTOH, fixing either probably makes fixing the other simpler.

(In reply to Todd M. Lewis from comment #86)

This was marked as a duplicate of bug #1686556, but that's not accurate. In that other bug, I was saying that messages previously viewed in the current session, and later returned to, should retain their scroll position. This is orthogonal to tabs.

The two are at least related, bug #1686556 is a problem that needs fixing even if Thunderbird didn't have tabs.

OTOH, fixing either probably makes fixing the other simpler.

Its the other way around, bug #1686556 was marked a duplicate of this.

But I do agree that its different problems.
This one is about keeping track of multiple scroll positions at the same time in the gui.

bug #1686556 is about storing scroll position in the mailbox file for later retrieval. Yes they will affect each other but it most likely is two different sets of code that needs addressing.

Depends on: 1695098
Blocks: 1736337

Something that has been bugging me for a long time now, but saw a notification about this bug and wanted to ask about it...

I get frustrated by different tabs not allowing for different Accounts in the Accounts List Pane being expanded/collapsed...

Specifically: I want one tab to have certain accounts expanded and the rest collapsed, while other tabs have a different set of Accounts expanded/collapsed.

I think that should be covered by this bug, but - should I open a new bug for this, or would this be covered by this bug?

Anyone? Should I open a different bug?

This is actively being worked on in other bugs for re-working how the 3pane functions. The fix will be in the 2023 release, and available only preffed off for Thunderbird 102 this year (since you'll have to accept rough edges if you enable it).

Restrict Comments: true
Depends on: 1729384

(In reply to Charles from comment #89)

Specifically: I want one tab to have certain accounts expanded and the rest collapsed, while other tabs have a different set of Accounts expanded/collapsed.

Hello Charles, thank you for sharing your UX concerns as a user of Thunderbird and your suggestion/expectation for improvement, which makes sense to me.

I think that should be covered by this bug, but - should I open a new bug for this, or would this be covered by this bug?

Thanks for asking! No need to open a new bug. Your issue belongs to the symptoms covered by this bug. Like all other symptoms of this bug, it will be fixed by bug 1729379 which is currently work in progress and expected to land in the next release version of Thunderbird (mid 2023).

In the meantime, you could use the following workaround:

How to show different accounts expanded/collapsed in separate views

  • Right-click on any folder > Open in a new window
  • Expand/collapse folders in each window according to your preferences.
See Also: → 541876

Current status of this bug

Thanks everyone for sharing their legitimate user experience (UX) concerns as users of Thunderbird and your suggestions/expectations for improvement, and sorry for the inconvenience caused by this bug!

  • The Thunderbird team is aware of this bug and is actively working on a systemic and sustainable solution in bug 1729379 which addresses the root cause of the problem once and for all rather than just patching over symptoms. The architectural changes required for that are massive.
  • Bug 1729379 (which will fix this bug) is expected to land in the next release version of Thunderbird (mid 2023). Thank you for your patience.

In the meantime, let's please remain respectful and cooperative - this bug is very popular and it's relevant, but so are others. I appreciate the frustration, but I've also come to see that there's so many factors in the mix. Thunderbird has undergone varying manpower situations throughout the years, better now. With each release we're fixing loads of things, but we also need to remove technical debt, modernize and add features to remain viable and competitive. There's tons of great features in Thunderbird, and you're getting all of them for free. Big improvements are happening after all - look at the new address book! Btw, if you like Thunderbird, the best way to ensure Thunderbird remains available and well-maintained is to make a donation.

(In reply to Magnus Melin [:mkmelin] from comment #83)

This is an important bug. It just requires very significant changes.

(In reply to Magnus Melin [:mkmelin] from comment #96)

This is actively being worked on in other bugs for re-working how the 3pane functions. The fix will be in the 2023 release, and available only preffed off for Thunderbird 102 this year (since you'll have to accept rough edges if you enable it).

Depends on: tb-new-3pane
No longer depends on: 535373, 590910, 545666
Summary: tabs don't maintain exactly what was shown when switching tabs (e.g. reload feed page, loss of message scroll position, text selection, focus, attachment pane UI state) [not remember, lose, forget, unwanted display refresh changes, reset] → Tabs don't maintain exactly what was shown when switching tabs (e.g. reload feed page, loss of message scroll position, text selection, focus, attachment pane UI state) [not remember, lose, forget, reset] - current status: see comment 99
Whiteboard: [ux-papercut][duptome][gs][UXprio][tb-papercut][blocked on bug 545666 and friends] → [ux-papercut][duptome][gs][UXprio][tb-papercut][will be fixed by bug 1729379 and friends, WIP]
See Also: → 1733804
Duplicate of this bug: 1805287

bug 1729379 is largely completed in version 115.
Version 115 will be available in a few weeks.

Does this reproduce for you in version 115?

Flags: needinfo?(utoddl)
Flags: needinfo?(tanstaafl)
Flags: needinfo?(sdsol)
Flags: needinfo?(dmartensson)
Flags: needinfo?(chris)
Whiteboard: [ux-papercut][duptome][gs][UXprio][tb-papercut][will be fixed by bug 1729379 and friends, WIP] → [closeme 2023-08-11][ux-papercut][duptome][gs][UXprio][tb-papercut][will be fixed by bug 1729379 and friends, WIP]

Let's make a clean break. The code is new in version 115, so if anyone still sees an issue in version 115, please file a new bug report.

Status: NEW → RESOLVED
Closed: 7 months ago
Flags: needinfo?(utoddl)
Flags: needinfo?(tanstaafl)
Flags: needinfo?(sdsol)
Flags: needinfo?(dmartensson)
Flags: needinfo?(chris)
Resolution: --- → INVALID

This was fixed by the supernova rework.

Resolution: INVALID → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: