Closed
Bug 953904
Opened 10 years ago
Closed 10 years ago
Unread status doesn't disappear when the tabbar-tab (instead of the content of the tab) had the focus when the selected tab changed
Categories
(Instantbird Graveyard :: Conversation, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
1.2
People
(Reporter: clokep, Assigned: aleth)
Details
Attachments
(2 files, 2 obsolete files)
37.77 KB,
image/png
|
Details | |
6.04 KB,
patch
|
florian
:
review+
|
Details | Diff | Splinter Review |
*** Original post on bio 465 at 2010-08-04 01:41:00 UTC *** When a message is received on a background tab the unread styling is properly applied. But if this tab is navigated to via the keyboard (press tab, which should select your current tab) then left/right (or up/down) to move through the tabs. When the unread tab is reached the text will not change back to the normal state and will stay in the unread state (i.e. the text stays red). Steps to reproduce: 1. Open at least 2 conversations 2. Receive a message in the background conversation 3. Press tab 4. Move to the conversation that received the message with the arrow keys Expected outcome: The message should no longer be unread (the text should go to black, as if you click on it or Ctrl+Tab to it) Actual outcome: The text stays red as if the message is still unread. Tested with and without Vertical Tabs and three computers (all running Windows 7).
Comment 1•10 years ago
|
||
*** Original post on bio 465 at 2010-08-04 08:49:06 UTC *** The STR give the same result (ie the bug) on Ubuntu 9.10. for the normal tabs. I guess Windows 7 and Ubuntu are different enough to justify a platform PC/ALL.
OS: Windows 7 → All
Comment 2•10 years ago
|
||
*** Original post on bio 465 at 2010-08-20 18:27:01 UTC *** (In reply to comment #1) > The STR give the same result (ie the bug) on Ubuntu 9.10. for the normal tabs. > > I guess Windows 7 and Ubuntu are different enough to justify a platform PC/ALL. Problem is that the unread-status is unset when the tab is focused. Going through the tabs on the tab bar doesn't fire focus (you wouldn't like that either at the moment as it would move the focus to the chat input field at the moment).
Comment 3•10 years ago
|
||
*** Original post on bio 465 at 2011-09-10 23:07:37 UTC *** The mentioned problem can also happen when the focused tab is closed while it had the focus on the tabbar-tab itself (and not in the conversation content, participant list, input box ..) and the next tab to show has unread messages. This is not limited to keyboard interaction, closing the other tab by clicking the close button also leads to the same problem here. Changing the summary accordingly.
Summary: Unread status doesn't disappear when navigating to tab from keyboard → Unread status doesn't disappear when the tabbar-tab (instead of the content of the tab) had the focus when the selected tab changed
Comment 4•10 years ago
|
||
*** Original post on bio 465 as attmnt 812 at 2011-09-10 23:10:00 UTC *** Since the verbal description might have been a bit confusing, here's a serious of screenshots: Order is from top to bottom, interacting with the mouse (i.e. pressing the close button).
Comment 5•10 years ago
|
||
*** Original post on bio 465 at 2011-09-10 23:12:43 UTC *** Oops, a typo. While it might be *serious* for some, I meant a *series of screenshots* of course.
Assignee | ||
Comment 6•10 years ago
|
||
*** Original post on bio 465 as attmnt 1719 at 2012-06-29 16:19:00 UTC was without comment, so any subsequent comment numbers will be shifted ***
Attachment #8353477 -
Flags: review?(clokep)
Assignee | ||
Updated•10 years ago
|
Assignee: nobody → aleth
Status: NEW → ASSIGNED
Assignee | ||
Comment 7•10 years ago
|
||
*** Original post on bio 465 at 2012-06-29 16:25:54 UTC *** It just struck me that onSelect (or at least onselect) may be a protected method name for XBLs? Not that the above patch produces any warnings, but should it be renamed?
Comment 8•10 years ago
|
||
*** Original post on bio 465 at 2012-07-11 11:22:29 UTC *** I remember at some point we had a timer to mark a conversation selected this way as read only after some time (I guess it was just focusing it), to avoid marking all conversations as read when just keeping the right arrow pressed (or pressing it several times in a row) to select a conversation that isn't the next one. Also, when a tab was selected with the keyboard in this way, it may be surprising that starting to type a message doesn't work if the user hasn't focused the editor first.
Assignee | ||
Comment 9•10 years ago
|
||
*** Original post on bio 465 at 2012-07-11 11:27:50 UTC *** (In reply to comment #8) > I remember at some point we had a timer to mark a conversation selected this > way as read only after some time (I guess it was just focusing it), to avoid > marking all conversations as read when just keeping the right arrow pressed (or > pressing it several times in a row) to select a conversation that isn't the > next one. Good idea. > Also, when a tab was selected with the keyboard in this way, it may be > surprising that starting to type a message doesn't work if the user hasn't > focused the editor first. It sounds like you are suggesting we call focus() after the above brief timeout. I can simply reuse the timeout from bug 954884 (bio 1450).
Comment 10•10 years ago
|
||
*** Original post on bio 465 at 2012-07-11 13:40:13 UTC *** I said we used to have a timeout, not that we necessarily want to have one again. If we want a timeout again, ensuring it's the same as the one added in bug 954884 (bio 1450) would be good. The solution without timeout would be to just focus the textbox when the user starts to type while the tab is focused (we currently do this if the user types while the browser is focused). I don't have a strong opinion either way. With comment 8 I was mostly trying to provide some background/context information.
Assignee | ||
Comment 11•10 years ago
|
||
Comment on attachment 8353477 [details] [diff] [review] Patch *** Original change on bio 465 attmnt 1719 at 2012-07-12 10:53:47 UTC was without comment, so any subsequent comment numbers will be shifted ***
Attachment #8353477 -
Flags: review?(clokep)
Assignee | ||
Comment 12•10 years ago
|
||
*** Original post on bio 465 as attmnt 1739 at 2012-07-13 19:48:00 UTC *** >I said we used to have a timeout, not that we necessarily want to have one >again. >If we want a timeout again, ensuring it's the same as the one added in bug 954884 (bio 1450) >would be good. >The solution without timeout would be to just focus the textbox when the user >starts to type while the tab is focused (we currently do this if the user types >while the browser is focused). So, I experimented a bit and settled for a short timeout to prevent tabs from being marked as read if the user is just scrolling past them with the arrow keys. The timeout from bug 954884 (bio 1450) feels too long here. The reason is that here, we know the user's attention is on IB as she is switching between tabs, so it feels odd if there is a noticeable delay between switching to a tab and marking it as read. (While in bug 954884 (bio 1450), the timeout is precisely to distinguish between IB being focused "by accident" and a time after which we can reasonably assume the user has "noticed" IB.) If the user starts to type, the editbox is focused - this seemed a good suggestion to me independent of everything else.
Attachment #8353499 -
Flags: review?(clokep)
Assignee | ||
Comment 13•10 years ago
|
||
Comment on attachment 8353477 [details] [diff] [review] Patch *** Original change on bio 465 attmnt 1719 at 2012-07-13 19:48:11 UTC was without comment, so any subsequent comment numbers will be shifted ***
Attachment #8353477 -
Attachment is obsolete: true
Assignee | ||
Comment 14•10 years ago
|
||
*** Original post on bio 465 at 2012-07-13 19:50:20 UTC *** I'm not sure if I haven't missed some accessibility keys, e.g. for opening the context menu, as I don't know what they are.
Assignee | ||
Comment 15•10 years ago
|
||
*** Original post on bio 465 as attmnt 1740 at 2012-07-13 20:22:00 UTC *** Expanded comment as requested. Tested that it doesn't break the Linux "open context menu" key.
Attachment #8353500 -
Flags: review?(florian)
Assignee | ||
Comment 16•10 years ago
|
||
Comment on attachment 8353499 [details] [diff] [review] Patch *** Original change on bio 465 attmnt 1739 at 2012-07-13 20:22:42 UTC was without comment, so any subsequent comment numbers will be shifted ***
Attachment #8353499 -
Attachment is obsolete: true
Attachment #8353499 -
Flags: review?(clokep)
Comment 17•10 years ago
|
||
Comment on attachment 8353500 [details] [diff] [review] Patch *** Original change on bio 465 attmnt 1740 at 2012-07-14 13:56:34 UTC *** Thanks for taking care of this!
Attachment #8353500 -
Flags: review?(florian) → review+
Reporter | ||
Comment 18•10 years ago
|
||
*** Original post on bio 465 at 2012-07-14 14:32:32 UTC *** Fixed with http://hg.instantbird.org/instantbird/rev/d24f6643270f Thanks!
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.2
You need to log in
before you can comment on or make changes to this bug.
Description
•