Tested scrolling in live chat component in Windows 8.1, IE 11, Dell Inspiron 7537 laptop with trackpad. Scrollbleed occurs:

1. Starting at URL: https://lit-cove-83883.herokuapp.com/
2. Log in using WPcom credentials and open chat (someone needs to be logged into HUD)
3. Chat enough to create scroll.
4. Expand window to full screen to create chat sidebar.
5. Hover over (or click into) chat sidebar and start scrolling.
6. When at the end of chat scrolling, scroll jumps to main window and begins scrolling the Reader.
7. Resize window to create chat panel instead of chat sidebar. 5&6 still happening.
8. Resize window to create full screen chat. Though the chat covers the main page, you can still see the scroll marker moving for the main page when at the end of chat scroll.

cc: @jasmussen

When scrolling through Insights and other stats screens in Calypso, a small amount of white at the edge of the text field bleeds through to the chat panel:

Steps to reproduce:

1. Go to https://lit-cove-83883.herokuapp.com
2. Log in with WPcom credentials.
3. Resize window so that chat becomes small panel instead of sidebar.
4. Navigate to My Sites > Stats
5. Scroll through the different stats screens.
6. See white edges of fields, eg. in the Comments section of the Insights screen, or the Followers section (sections must contain content for this to occur).

Occurs in both Firefox and Chrome on MBP.

cc @jasmussen

When you shrink the browser window so that the chat sidebar changes into a chat panel, the scroll bar of the chat panel jumps upwards, meaning that the user has to scroll down again to get to the last typed text.

Screen capture -
https://cloudup.com/cE9GrWjkJZD

Steps to reproduce

1. Open a browser window, load the user facing site, and make sure the window is large enough for the chat sidebar to appear
2. Start a chat as a user
3. Resize the browser window so the chat sidebar changes into the chat panel

The "Customize" option next to Themes in the Calypso sidebar appears to be the only option linking to a non-Calypso page, which means if the user selects it while chatting with us they will no longer be able to see their chat until they navigate back to Calypso, and then it may be collapsed and hard to find. If feasible, we should force Customize to open in a new tab if the user has an active chat session with us.

When a user receives a new chat message from an operator but is not in the chat (is looking at another window/tab, etc), provide a visual notification that there is a new message via Calypso notifications.

Separated out from #7 for easier tracking

Agent W., though it has CSS for extra functionality, is mostly a flat SVG right now. Still, it's a component built for easter eggs and more, but it's currently only in the HUD: https://github.com/Automattic/tinkerchat-hud/tree/master/src/lib/agent-w

I tried adding it to the live-chat component, but couldn't find a great clean way to do it.

Steps to reproduce

1. Starting at URL: https://lit-cove-83883.herokuapp.com/
2. Open chat using Support Chat link in left footer
3. Send enough messages to require scrolling in the chat sidebar/panel
4. Type a long message in the input field. When the long message is long enough to require scrolling in the input field, attempt to scroll the input field before sending the message.
5. Hover over or click into input field and attempt to scroll.
6. Chat sidebar or panel scrolls, but input field does not.

I expected the input field to scroll when it is active or when I hovered over it. Instead, the chat sidebar or panel scrolls. Tested in Firefox, Chrome, and Safari in OSX El Capitan and it occurs in all three browsers

Thank you @dllh for reporting and for the gif.

What I expected

After completing a chat. I'd like to close a chat as user or from the agent's side.

What happened instead

The chat goes on endlessly. Closing the chat window doesn't end the chat.

Browser / OS version

Chromes / OSx El Capitan

Currently, if a user has an active chat at /me/chat and navigates to another part of Calypso, such as Stats, the chat is hidden and must be reopened by clicking "Support Chat" in the sidebar.

Instead, if a user has an active chat at /me/chat and clicks to another Calypso page we should automatically expand the chat so they don't lose the conversation and need to find that link. This seems especially likely to happen if we're providing Calypso links to them in the chat and they users follows them.

Originally reported by @kriskarkoski in https://github.com/Automattic/happychat/issues/99

We recently changed all links to open in a new tab to avoid users losing chat unexpectedly when we send them anywhere other than Calypso, but in testing this means that Calypso links open in a new tab with chat closed and clicking the Support Chat link again loses the chat history.

We should improve this before launching to users to open all Calypso links in the same tab so chat can follow the user, while WP Admin, en.support, and any other non-Calypso links open in a new tab so chat remains open in the original tab.

Related: #6 (comment)

Originally reported by @kriskarkosi in https://github.com/Automattic/happychat/issues/98:

Chatting as a user, typing lags in Safari (seen in 9.1.3) even on a brand new chat. Reported by @shaunandrews during our a8c testing. Video of the issue below:

Similar sounding issue in https://github.com/Automattic/happychat-hud/issues/358, but the cause there seems to be a long chat history, which was not the case here.

I tried to replicate this in Safari on 9.1.3 in OS X El Capitan 10.11.6 today but was unable.

When a user opens a new chat in Happychat, they receive this message:

This is the beginning of your chat history with WordPress.com support. A chat history will be stored here.

Until https://github.com/Automattic/happychat/issues/8 is implemented, we should change this message to:

Welcome to WordPress.com support chat!

or something similar :-)

When window is sized such that live chat is the small panel instead of the full sidebar, the panel is obscured by the custom menu when on the Calypso menus screen at /menus: https://lit-cove-83883.herokuapp.com/menus/{siteURL}:

It is not possible to click the chat to bring it forward. Tested in Chrome and Firefox with same results. Steps to repro:

1. Go to https://lit-cove-83883.herokuapp.com
2. Log in with WPcom credentials.
3. Resize window so that chat becomes small panel instead of sidebar.
4. Navigate to My Sites > Menus
5. Find a menu with several items on it (or create one), such that the menu extends low enough that it overlaps with the chat panel.
6. Menu obscures chat panel and it is not possible to see or access the chat.

When the window is expanded so that chat becomes a sidebar instead of a panel, everything works fine.

Currently, when a longer URL is entered in the chat, the chat panel doesn't wrap it to the panel's exact dimensions, and instead clips the URL, and makes this extra content content accessible via both a horizontal and a vertical scrollbar.

That chat panel should not display scrollbars here, and should instead wrap long URLs to the panel's exact dimensions.

When another window has focus, scrolling the chat (without clicking so focus remains on the other window) to the end will then scroll the main WordPress.com page being displayed.

If the browser window has focus, scroll behaves normally. The main page isn't scrolled while the cursor is in the chat panel.

Steps to reproduce:

1. open a chat long enough to scroll
2. click into a different window on your desktop
3. hover over the chat panel without clicking and scroll to the top/bottom of the chat
4. keep scrolling

Steps to reproduce

1. Starting at URL: Any Calypso URL, e.g. https://wordpress.com/
2. Make sure your browser window is wider than 1040 px and start a new chat
3. Resize the window so it is 1040 px wide or smaller

What I expected

I expected the chat window to respond to the smaller browser width/size.

What happened instead

The window "detached" from the sidebar (not connected to the right or top edges of the window) and just floated there, covering the content and not changing width until the window became smaller than the chat window's width.

Browser / OS version

Chrome 52.0.2743.116 / Mac OS X 10.11.6

Screenshot / Video

Context / Source

manual-testing

In testing, several folks asked "Will the X end the chat?" They indicated reluctance to click it in fear of closing the chat permanently. I recommend changing the X to a character that suggests minimization rather than closure.

The X looks so permanent:

Steps to reproduce

1. Starting at URL: https://wordpress.com/
2. Click "Support Chat" to start a new chat
3. Enter a message and go back and forth with the operator
4. Click on your Gravatar in the masterbar to go to the /me page
5. Click "Support Chat" in the left sidebar to go to https://wordpress.com/me/chat

What I expected

I expected to see a full-screen chat.

What happened instead

I saw the full-screen chat with the chat sidebar overlapping it on the right.

Browser / OS version

Chrome 52.0.2743.116 / Mac OS X 10.11.6

Screenshot / Video

Context / Source

manual-testing

Mockup:

Calypso has a new permanent sidebar footer, which would be a good place to put a "Support Chat" link when support is available.

In preparation for the beta of Happychat we need to tweak how users access chat to match how Olark is currently implements so we can staff both platforms while Happychat is in testing.

To do this, Happychat chat sessions should be started only from the wordpress.com/help/contact page (which is linked from wordpress.com/help, which is accessed from the Help option at the bottom of the Calypso sidebar). The Support Chat option currently shown in Calypso on all pages should be hidden and only shown if the user has an active chat session so that they can reopen chat with us if they've closed it for some reason.

It's not essential, but it would be nice to have the Support Chat link show in a different color than black (maybe orange) if they have a new message from us that they haven't seen yet.

This change should also make initial implementation of https://github.com/Automattic/happychat/issues/16 more straightforward since it can use a full page form like we do now on /help/contact.

On narrower screens the Happychat window is not docked in full-height on the right side, but instead floats in the bottom-right corner and covers over half of the width, which feels out of place since it covers elements of Calypso. I think we should either make it narrower to be more into the right-corner like our previous chat implementation or take up the full-width on the bottom of the screen.

Before Happychat is launched to staging for A12S, let's add a message for users who open chat when there are no available agents:

No agents are currently available to chat. If you'd like to become available as an agent, log in at happychat.io.

In a browser window that is narrow enough for Happychat to no longer takes up the full right side it is occasionally displaying in an extra wide version rather than the smaller version docked in the bottom right corner.

Here is how it should look:

And here is how it's occasionally displaying:

Both of these were seen in Chrome 53 on OS X 10.11.6.

@andreabadgley added:

I got the wide chat as a user, then typed something and it got small
Then Agent W replied with no opers available and it got wide again

When a user receives a new chat message from an operator but is not in the chat (is looking at another window/tab, etc), provide a subtle audible notification or visual notification to browser tab.

Steps to reproduce

1. Starting at URL: https://lit-cove-83883.herokuapp.com
2. Resize screen so that chat expands to right sidebar.
3. On Reader, chat sidebar obscures right side of posts.
4. Click to My Sites > Stats.
5. Chat sidebar covers right hand side of stats.
6. Click around other Calypso screens; chat sidebar covers the right side.

It looks like the Calypso screen is not centering between the left and right sidebars but is instead keeping its original centering, and the chat sidebar covers it on the right side.

Browser / OS version

OS X El Capitan, Chrome, Firefox

Screenshot / Video

https://cloudup.com/c4Cw_z9nSGY

What I expected

I expected the margin around the chat to have more breathing room at desktop widths—I think the margin is something like 32px at the largest breakpoint. As the window gets smaller the margin should diminish. Similarly, the text input could either have a margin around it or more inner padding at large widths.

What happened instead

There are 8px of left/right padding around chat messages regardless of breakpoint. The design works wonderfully at mobile width, but feels too pinned to the corners on larger screens. The reading experience was a little bit tough as a result.

Links in the user client are a bit hard to read. Can we increase the contrast? In the HUD, the hex color for links is #9FE9FC.

Here's what they look like in the user client:

Here's what they look like in the HUD:

When an operator provides a URL for a user to click in chat, the URL is not clickable. User must copy URL and paste into browser to open the link.

Currently, when a user has an active chat there is an "X" at the top of the chat to minimize it:

I'd suggest clarifying the UI so users understand that this only minimizes the chat. When I saw it, I assumed that clicking the "X" would end the chat and disconnect me from the operator, so I was hesitant to click it.

I would be more confident if it were a more familiar "minimize" icon. (If users also eventually have an option to end/disconnect the chat, that could be represented with the "X" icon alongside the minimize icon.)

Currently the chatbot looks like this:

We should update Wapuu's nickname (meta.nick, don't know where that's stored) so it shows up right as the img alt text. We should also not show it in the chat itself. My assumption is right now that it's unnecessary info, if we find out otherwise during the test we can add it back.

CC: @beaucollins

When user's chat tab is not focused, provide a browser sound notification when agent has left a new message.

Separated out from #7 for easier tracking

On several screens in Calypso, interface elements such as buttons and labels currently clip through the chat panel.

This was reported in #8 and was fixed, but is happening still. I thought I could reopen the issue, but I can't so I'm re-reporting. The clipping is happening on the Heroku instance as of July 27, 2016. If Heroku isn't running current updates that fix this, feel free to close the issue again :-).

https://lit-cove-83883.herokuapp.com/me/billing

https://lit-cove-83883.herokuapp.com/design

As the user navigates around Calypso, we need to track their current page and report that to the service as an event (navigation?)

We need to limit the event such that it's not visible to the user (only operators [and bots?]).

Needed for https://github.com/Automattic/tinkerchat-hud/issues/49

Steps to reproduce

1. On a mobile device, starting at URL: https://wordpress.com/
2. Tap "Followed Sites" at the top to open the Reader sidebar
3. Tap "Support Chat" to start a new chat — you are directed to https://wordpress.com/me/chat to start the chat
4. Enter a message and start chatting with an operator
5. Tap on a link in the masterbar to navigate around Calypso — the chat window disappears
6. Find the "Support Chat" link wherever you are and tap it to open chat again

What I expected

I expected the chat window to follow me around Calypso (step 5 above), as it does on a desktop browser.

When the chat window disappeared, and I opened chat again (step 6 above) I expected it to reopen my chat where I had left off.

What happened instead

The chat window didn't follow me around (step 5 above); I had to hunt for the "Support Chat" link again to reopen it.

And after the chat window disappeared, and I opened chat again (step 6 above), it redirected me back to https://wordpress.com/me/chat, refreshed the screen, and started me over with a brand new chat (no chat history showing from before I navigated away).

Browser / OS version

iPhone 6, iOS 9.3.5, Chrome app

Context / Source

manual-testing

This may be a wontfix, but currently with Olark, users see a short notification that the operator has ended the chat. It appears that Happychat doesn't have this at the moment from my testing.

On several screens in Calypso, interface elements such as buttons and labels currently clip through the chat panel.

Billing History - /me/billing

My Sites > Menus - /menus/

My Sites > People - /people/team/

Will update this thread with more examples, as and when I find them.

As an added bit of info for HEs, when a user initiates a chat, we should grab a batch of data about the user's browser and system and send that to the service so it's available in the HUD.

Opening Happychat while in the Post editor (wordpress.com/posts) forces the "Edit Post URL" link icon off screen:

Here's what it looks like without Happychat open:

Instead, we should indent the icon and title with Happychat open so it remains accessible like it does in a narrower browser window:

The issue is also present in the Page editor, but looks slightly different since the permalink is always visible there. Instead, the link icon is mostly cut off:

It should look more like this with the icon remaining visible in narrower windows (though there looks to be some existing padding issues):

All of these were seen on OS X 10.11.6 in Chrome 53

Steps to reproduce

1. Starting at the front page of your site
2. Click the Gravatar in the admin bar to open the /me menu
3. Look for "Support Chat" link (nothing appears under the Help link)
4. Click on "My Profile" to open https://wordpress.com/me
5. Look for "Support Chat" link (appears under the Help link in the sidebar)

What I expected

I expected the links in the /me menu on the front of the site (under the user's Gravatar in the admin bar) to match the links in the sidebar at https://wordpress.com/me

What happened instead

There is no Support Chat link in the /me menu on the front of the site.

Browser / OS version

Chrome 52.0.2743.116 / Mac OS X 10.11.6

Screenshot / Video

Front of site:

Sidebar at https://wordpress.com/me:

Context / Source

manual-testing

Tested scrolling in live chat component in Safari on iPad. Steps to reproduce:

• Start at URL in Safari on iPad: https://lit-cove-83883.herokuapp.com/
• Log in using WPcom credentials and open chat (someone needs to be logged into HUD)
• Chat enough to create scroll.
• Start scrolling in chat panel on iPad.
• When at the end of chat scroll, scroll jumps to main window and begins scrolling the Reader.

Bleed occurs in both portrait and landscape views.

cc: @jasmussen

Steps to repro:

1. Open Safari in OSX El Capitan
2. Start at URL: https://lit-cove-83883.herokuapp.com/
3. Click Support Chat link in left footer
4. Nothing happens -- support chat does not open as expected.

If you initiate a new chat from stats/insights/siteurl the posting activity graph is cut off by the chat sidebar.

Steps to reproduce

1. Open the Insights page for a site. e.g. https://wordpress.com/stats/insights/andrewspittle.com
2. Click "Support Chat" to start a new chat.
3. Note the display of the "Posting Activity" section of the page.
4. The most recent month or so will be cut off.

You can see this in the blow screenshots. First, this is what the posting activity graph looks like when first opening the page:

This, then, is what it looks like after you start a chat.

Note how half of August and all of September is cut off. Ideally initiating a chat should not cause part of the page to be cut off.

I tested this in Safari 9.1.2 on OS X.

If a user is in an ongoing chat with us, and logs in from another browser/session, new chat messages that come in after they login, appear in the new browser/session.

However, chat messages that have already been sent do not get synced across to the new browser session automatically. Ideally, the user should see the existing chat messages when they login from a new browser/session.

Steps to reproduce

1. As a user, start a chat from one browser/session
2. Login as the same user from another browser/session, and open chat
3. New messages will across both browsers/sessions, but existing messages will not

Steps to reproduce

No Notification When User Scrolls Up in Conversation:

1. Starting as user, log into chat.
2. Begin conversation with operator. Operator responds.
3. Create enough of a conversation for a reasonable backscroll. (Note that the scroll does not follow the conversation--it stays at the top.)
4. Operator responds as user is reading the backscroll above.
5. There is no notification/indication that the operator has responded.

No Notification to user that operator has responded in first chatbox window (when opening multiples)

1. Starting as user, log into chat.
2. Begin conversation with operator. Operator responds.
3. Click operator link to open second calypso browser and/or open another calypso page.
4. Open second chatbox for operator. Write message to operator in second window.
5. Operator responds--user will see the operator's response in the second chat window.
6. Go back to first chat window--it looks as though operator did not respond, however, if you scroll down, you can see the operator.

What I expected

If a user scrolled up in a chat to read something that was sent before, I expected to either have the chat jump back down to the operator response or have some sort of notification.

Additionally, as the chats get longer and longer, the scroll does NOT follow the conversation; it sticks to the top.

Across multiple chats--operator's instructions to continue across multiple chat boxes.

What happened instead

When a user scrolls up towards the top, they don't get any kind of notification that an operator has replied to the user and that he or she should scroll down.

This is similar to #16 (ongoing chat does not sync across browser sessions)--along with the async across chats, if a user opens a second chatbox in a second chat window and the operator responds, the text from the operator will appear in the second window. It will ALSO appear in the first chatbox, but there's no indication that they should scroll down.

Browser / OS version

Chrome 52, OSX

Screenshot / Video

Example of chat not scrolling with lengthier conversation:

I'd typed quite a bit and my operator had replied as well, but it did not scroll down.




Conversation continued across both chats, BUT there was no indication that the operator had responded when I switched back to the first chat (when I was looking at the second screen). A notification to scroll down would be very helpful!

Second Chat Window--I can see that the operator responded since I was looking at this window.



First Chat Window: Since this screen was not open in my browser, it looked like the operator did not respond in my first chat box (when I eventually switched back.) Conclusion Operator's response DOES load into the first window, but only if I scroll down. There was no indication that I, the user, should scroll down to see it.

Tested on MacBook Pro in Safari using trackpad. A couple of minor issues:

1. When Safari is not focused, main body scrolls when hovering over chat, as reported in #12 (The reverse is not true: when Safari is not focused, only the main body scrolls when hovering over the main body -- chat does not scroll when hovering over main body).
2. When Safari is focused, scrolling works as expected when hovering over chat, in that scrolling doesn't bleed into main body at end of chat scroll. However, there is sometimes a small bounce in the main body on the 3rd - 10th swipe.

Here's a 1:08 video showing the issues above when chatting as user in Safari at https://lit-cove-83883.herokuapp.com/:

https://cloudup.com/cze2D3R2lPq

cc @jasmussen

Originally reported in https://github.com/Automattic/happychat-hud/issues/318 by @eduardozulian:

At the moment, we are using the same chat bubble for both user and operator:

The idea here is just flip the tail and other elements to point the chat bubble directly at the user:

Steps to reproduce

1. Starting at URL: https://wordpress.com/
2. Click "Support Chat" to start a new chat
3. Enter a message and go back and forth with the operator
4. Click "My Sites" in the same browser tab

What I expected

I expected the chat to follow me to the new page.

What happened instead

I lost the chat. The chat sidebar (on the right) closed, and when I clicked "Support Chat" again it opened a new chat window to start a new chat. I never got the previous chat back.

However, my operator (Andrea) still had my chat and I could continue chatting with her.

I then tried visiting other Calypso pages, and I couldn't reproduce the issue even when I switched from the Reader to the My Sites page again later. The chat followed me between pages as expected after that.

Browser / OS version

Chrome 52.0.2743.116 / Mac OS X 10.11.6

Context / Source

manual-testing

Steps to reproduce

1. In a desktop browser, starting at URL: https://wordpress.com/
2. Click "Support Chat" to start a new chat
3. Enter a message and start chatting with the operator
4. In a mobile browser, open https://wordpress.com/me/chat
5. Continue chatting with the operator (note the previous messages from the desktop browser won't appear in the mobile browser, per #16, but new messages should appear in both browsers)
6. Let both chat windows sit for a minute or so
7. Start typing in the desktop browser again

What I expected

I expected all messages to be synced across browsers once I was chatting in both, so any new messages typed on desktop would appear on mobile, and vice versa.

What happened instead

The first message I typed after pausing and then resuming the chat on desktop didn't appear in my mobile browser. All messages after that were synced as expected, even when I switched quickly between browsers.

(I'm not sure if the pause (step 6 above) was the cause of the unsynced message, but it's the only other factor I could identify. I have not reproduced the issue since the first time it happened.)

Browser / OS version

Desktop: Chrome 52.0.2743.116 / Mac OS X 10.11.6
Mobile: iPhone 6, iOS 9.3.5, Chrome app

Screenshot / Video

Chat in the desktop browser:

Chat in the mobile browser:

Context / Source

manual-testing

With Happychat open the Posts list at https://wordpress.com/posts/ has some display issues, notably the Drafts sidebar is very narrow and "See all drafts (#)" runs onto a new line. It looks like we're just missing the cutoff for the Drafts moving into the top nav next to published so we may just need to tweak the cutoff slightly.

Seen on OS X 10.11.6 in Chrome 53 at 1280x800.

Here's what the Posts list looks like once the browser width is under the 700px cutoff:

The same issue is not present on the Pages list because it doesn't have the Drafts sidebar.

Steps to reproduce

1. Starting at URL: https://wordpress.com/design
2. Select a site and click the Support Chat link to start chatting
3. Click on a theme to view the theme info page (problem 1)
4. Click the "X" on the chat to close it (problem 2)
5. Go back to the All Themes page and click Support Chat to find the chat again
6. Click on a theme to view the theme info page again
7. Click the Setup or Support tabs on the theme info page
8. Click a link on either the Setup or Support tabs (problem 3)

What I expected

Problem 1:
I expected the chat window to appear to the right of the theme info.

Problem 2:
I expected to be able to reopen the chat window after I closed it.

Problem 3:
I expected the links on the theme info page to open in a new window, or to bring my chat with me when I clicked on them.

What happened instead

Problem 1:
The chat window overlaps the theme info.

Problem 2:
The chat window disappears, and there is no Support Chat link to reopen it. (You have to go back to the All Themes page and click Support Chat to reopen it.)

Problem 3:
The links in the theme info page open in the same tab, and they aren't in Calypso, so I lose my chat entirely.

When I go back (with the browser back button), the theme info page doesn't show the chat window anymore. When I go back again (with either the browser back button or the "<- All Themes" link on the page) the chat window isn't there. When I click Support Chat to open the chat again, it start a new chat, losing my previous chat.

Browser / OS version

Chrome 52.0.2743.116 / Mac OS X 10.11.6

Screenshot / Video

Problem 1:

Links that cause problem 3 (screenshot taken after I lost my previous chat and was prompted to start a new one):

Context / Source

manual-testing