Support `Messaging` view

[nexushoratio]

https://www.linkedin.com/messaging

• [x] #150
• [x] #204 A better selector helps.
• [x] #208 A better selector helps.
• [x] Standard scrolling of conversations (where would out-of-bounds go?)
• [x] Handle focus on message box while navigating
• [x] load more conversations
• [x] Scroller for conversation pane
• [x] Message box
• [x] ⋯ menu (both at the app level and conversation level, and conversations have buttons in both panes)
  • [x] #216
• [x] Star conversation (be consistent with any other pages, however)
• [x] Connect with other party (what happens with conversations with multiple people?) Too aggressive; too difficult to test.
• [x] focused / other (how will scrolling work?) (Per ARIA tab recs, once the tab gets focus, left/right arrows select)
  • [x] Monitor tablist for activity
  • [x] messaging tablist
• [x] New message
• [x] search messages
• [x] Video? (maybe, maybe not) Too difficult to test
• [x] Look through similar layout of Jobs Collections for further ideas

Unlikely to support anything for crafting messages.

[nexushoratio]

The UX for Messaging is unlike any other Page we have dealt with before. Not surprising really.

• Switching between Focused / Other conversation lists completely rewrites the container with conversations, which will require Scroller enhancements
• Switching conversation lists also keeps conversation pane on the same conversation. This means several things:
  • URL does not update, but current list is sticky. Page reload keeps current conversation, but it may not be present in the list. This is similar to what can happen with Job Collections, except that here, switching list will show it. Keeping LI's UI and Scroller in sync will be interesting.
  • ⋯ is only present on the pane (which means it should probably be the one always utilized)
  • If current conversation was lazily loaded, going away from and back to the associated list will mean it will need to be loaded again. When it does eventually show up, it becomes the active message again (similar to reload problem, but can happen any time later).
  • Moving conversation to a different list explicitly causes the above to happen (with the added bonus of the list can be out of sync itself). This means the current item in the scroller disappears.
• Conversation searching is another list. Resetting it appears to completely rewrite portions of the page, messing up Scroller's MutationObserver. It is also sticky.

[nexushoratio]

After the little bit of reading I've done on ARIA, particularly around tabs, I recognize some of what is happening on the Messaging view, that also happens on the MyNetwork/InvitationManager page.

The Focused|Other split (or Received|Sent) are <button>s with the role=tab attribute inside a <div role=tablist> (Also see #123 for some background.) In both cases, if a button has focus, then the left/right arrow keys (with or without modifiers) become active to navigate to the next tab in sequence (with wrapping). But, that only happens if those buttons have focus. Tab off of them, and the magic stops (also, only one button in the tablist has tabindex=0 at a time, the rest of the time it is -1. Related, the active button also gets the aria-selected=true attribute).

Anyway, despite the fact that both use the arrow keys to navigate, implementations are different. With InvitationManager, it goes to a different page. In Messaging, it does a major rewrite on the contents of what could be called the role=tabpanel element (if they actually used one).

It is not yet clear of the arrow key support for navigating the tabs comes from the browser or the app. More research is needed. But, it is clear that it is only active during focus. Only one member of the tablist is allowed to take focus at a time, so the tablist becomes the tab stop for tabbing (overloading the word tab here to mean both tabs in a widget, and the act of using the TAB key to navigate, as with old fashioned typewriter tab-stops).

So now that we understand what is happening, how can we make it better? If a user goes back and forth between the tables, which in this case both happen to be scrollable lists, do we try to maintain state for them? In the InvitationManager case, if the user does not notice that those are separate web pages, the UX would be that LIT maintains current active. Do we do the same here?

[nexushoratio]

Interesting gotcha: Whenever a new conversation is selected (either via keyboard, or via click), the focus immediately goes to the Write a message... text area. This means that navigating through conversations would require j TAB j TAB and so on.

[nexushoratio]

Working around the focus on the message box issue is not as trivial as I had hoped.

Scroller.#scrollBy() first resets the current item with this.item = this.item, which sends one change event, even though it is a no-op. Then, lines later, calls this.item = item to set it to the new item, which sends change again.

Oddly, in the callback, a randomly placed this.convoCards.item solves the problem. That is, invoking the getter interferes somehow, probably because it is mid-state change.

Maybe this information will lead to something interesting.

Hmmm.... seems the above working around the problem is inconsistent.

Ignore this whole comment. Has nothing to do with tracking down the bug or fixing it. Just some page loads get into a state that regularly triggers it, and some do not.

Not to say nothing was learned from this observation: Triggered twice may still be related. Just not calling back into Scroller.

I think I can reproduce this:

1. Click on message box giving it focus
2. TAB out of box
3. Navigate

Focus is now back in the message box, but it does not have the data-artdeco-is-focused attribute. Actually, it seems like that attribute is pretty undependable.

Once in the above state, it seems to stay there. It appears that clicking on a convo card will fix the issue.

Obviously, this is annoying, but since we appear to have a work around, it can probably be ignored for the moment. Maybe as we add more to the page, we can find a way to address this other than an onFocus handler.