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]

NEW
Unassigned

Status

defect
--
major
10 years ago
18 hours ago

People

(Reporter: yaoziyuan, Unassigned)

Tracking

(Depends on 3 bugs, Blocks 2 bugs)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [ux-papercut][duptome][gs][UXprio][tb-papercut][blocked on bug 545666 and friends], )

Attachments

(1 attachment, 1 obsolete attachment)

Reporter

Description

10 years ago
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
Reporter

Comment 3

10 years ago
whatever this fix may entail, it's the right direction and worth even architectural changes.
Duplicate of this bug: 489841
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.
Duplicate of this bug: 502879

Updated

10 years ago
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

Comment 9

10 years ago
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.
Duplicate of this bug: 515036
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)
Duplicate of this bug: 510823
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.
Duplicate of this bug: 522907

Comment 16

10 years ago
(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)
Reporter

Comment 17

10 years ago
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.

Comment 18

10 years ago
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.
Duplicate of this bug: 537740
Duplicate of this bug: 539027
Duplicate of this bug: 541786

Updated

10 years ago
Whiteboard: [duptome]
Duplicate of this bug: 545214

Comment 23

9 years ago
(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

Comment 24

9 years ago
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+
Duplicate of this bug: 569558
Duplicate of this bug: 569505
Duplicate of this bug: 576641
Duplicate of this bug: 581988

Updated

9 years ago
Whiteboard: [duptome] → [duptome] [gs]
Duplicate of this bug: 613456
Whiteboard: [duptome] [gs] → [duptome] [gs][UXprio]
Duplicate of this bug: 617975
Duplicate of this bug: 626412

Updated

8 years ago
Duplicate of this bug: 667914

Updated

8 years ago
Duplicate of this bug: 669055

Comment 35

8 years ago
There is a workaround I noticed with Thunderbird 5.0.  Use the conversations add-on.

Updated

8 years ago
Duplicate of this bug: 670101

Comment 37

8 years ago
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]

Updated

8 years ago
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]

Comment 38

8 years ago
Updating GS URL according to conventions.
Canonical GS report seems to be http://gsfn.us/t/1c54y.

Updated

8 years ago
Duplicate of this bug: 690261

Comment 40

8 years ago
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.

Updated

8 years ago
Duplicate of this bug: 717626

Updated

7 years ago
Duplicate of this bug: 515119
How many dupes (currently 22) are needed before the Thunderbird team decides to put this bug at the top of their TODO list? :)

Comment 44

7 years ago
(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...

Comment 45

7 years ago
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.

Comment 47

7 years ago
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.

Comment 48

7 years ago
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'.
Duplicate of this bug: 764760
Whiteboard: [duptome][gs][UXprio] → [ux-papercut][duptome][gs][UXprio]
Duplicate of this bug: 771629
Duplicate of this bug: 773946
Whiteboard: [ux-papercut][duptome][gs][UXprio] → [ux-papercut][duptome][gs][UXprio][tb-papercut]
Posted 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-

Updated

7 years ago
Depends on: 590910

Comment 57

6 years ago
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.

Comment 58

6 years ago
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

Updated

5 years ago
Duplicate of this bug: 981297

Updated

5 years ago
Duplicate of this bug: 1072876

Comment 63

4 years ago
(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.
Duplicate of this bug: 1216973

Updated

3 years ago
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]

Updated

3 years ago
Duplicate of this bug: 840623

Updated

3 years ago
Depends on: 535373

Comment 67

3 years ago
(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.

Comment 68

3 years ago
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?

Comment 69

2 years ago
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.)

Comment 70

2 years ago
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.

Comment 75

2 years ago
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.

Updated

2 years ago
Duplicate of this bug: 1342098

Updated

18 hours ago
No longer depends on: 537677
Duplicate of this bug: 537677
You need to log in before you can comment on or make changes to this bug.