Bug 487386 - tabs not maintaining scroll position.

Mark Banner mbanner at mozilla.com
Tue Jul 31 09:17:06 UTC 2012

On 30/07/2012 20:58, Kent James wrote:
> *Bug 487386* <https://bugzilla.mozilla.org/show_bug.cgi?id=487386>
> That bug has everything permitted within Bugzilla to scream for attention:
> [ux-papercut], [gs], [UXprio], 25 dups, 52 votes, major importance, 
> wanted-thunderbird, user whine with official "do not whine in BMO" 
> response, etc.
Yes, I'd agree it is a paper-cut bug.
> Yet unfortunately the answer to your question is "there are no plans 
> to address this bug".
Not quite true. We have discussed routes to improving Thunderbird which 
would also result in fixing this issue. They aren't simple and involve a 
big reworking of the way the main window UI works.

The SeaMonkey "ugly proof of concept" 
<https://bugzilla.mozilla.org/show_bug.cgi?id=541876#c1> is an 
interesting work around, although I'd be concerned that it could be 
fragile in itself. It also wouldn't fix some of the other related issues 
of feed pages/messages being reloading, text selection and focus.

Now I think about it, I don't think I've actually written down the 
direction I was originally thinking of going, so I'll do that and post 
it separately, as it isn't just related to fixing that specific bug.

The fundamental problem is that currently all message display tabs are 
using the same "messagepane" element (as well as other elements) - 
there's various assumptions all through the UI code that it exists, or 
that there's just one of them. This is also why we can't close the main 
3-pane tab at the moment.

To fix that is quite a lot of work, but I'll let you see that from the 
route I was proposing when I post it.

> Personally I think this is a travesty, and it is bugs like that that 
> get me motivated to improve our general qc process. Looking at the 
> papercuts list, I nominated it as a bug, but only got one supporter 
> for that, so it did not make the official first list. What we really 
> need is a group process */that we actually use to choose bugs to work 
> on/* where important stakeholds in Thunderbird have the opportunity to 
> influence which problems get addressed.
There's an important additional factor - the amount of work a papercut 
requires to fix. Whilst you can say it is important, if it will take a 
year of someone's work to fix, then maybe it isn't such a good choice, 
unless you are getting lots of user complaints (afaik we're generally 
just seeing them in bugzilla for this bug, and not on gs, but I've not 
looked myself).

The group process is much more interesting, and we should use the change 
of release & governance discussions to work out what we want there. 
Obviously we can't get everyone to work on just the bugs we want, but 
exploring that group process is something I'd like to see.

> There are existing processes in both BMO and gs that attempt to do 
> this. I don't really understand why those processes are not used in a 
> more effective way to influence development. People have followed our 
> process, this bug is easily a top 5 bug we should be looking at, yet 
> we don't.
It is always a balance of the bugs/features/time/visibility. In this 
case, I'd say that time to fix has been outweighing the others, and 
whilst it is visible to the users, it doesn't seem to cause the level of 
complaints that other bugs do.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20120731/46837026/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4123 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20120731/46837026/attachment.p7s>

More information about the tb-planning mailing list