search

RocketChat / Rocket.Chat.Electron

Official OSX, Windows, and Linux Desktop Clients for Rocket.Chat
https://rocket.chat/
MIT License
1.6k stars 707 forks source link

Links that are part of link preview handle differently #2331

Closed redRolf closed 2 years ago

redRolf commented 2 years ago

Description:

When you send a link, where the preview contains a link to a pdf, the file is opened within the rocket chat.

Clicking on the link in the red box causes the rocket.chat app to open the PDF within the app. image

Steps to reproduce:

  1. Send the following link in any channel: https://twitter.com/redguard_ch/status/1499290999159508992
  2. Click on the link in the red box image
  3. When using the app, you will now be stuck in the document view, with no UI element available to exit this view.
  4. The only way to exit the view is to click View -> Back, or to reload/restart the app.
  5. The same behaviour can be observed in the browser. But there the browser Back button can be utilised.

Expected behavior:

Actual behavior:

The file is opened within the app or browser.

https://user-images.githubusercontent.com/42872307/156535465-10382447-d088-4d69-8532-67f45c99031a.mp4

Server Setup Information:

Client Setup Information

Additional context

Relevant logs:

redRolf commented 2 years ago

Could be related or duplicate of: https://github.com/RocketChat/Rocket.Chat.Electron/issues/2222

Palanikannan1437 commented 2 years ago

Description:

When you send a link, where the preview contains a link to a pdf, the file is opened within the rocket chat.

Clicking on the link in the red box causes the rocket.chat app to open the PDF within the app. image

Steps to reproduce:

  1. Send the following link in any channel: https://twitter.com/redguard_ch/status/1499290999159508992
  2. Click on the link in the red box image
  3. When using the app, you will now be stuck in the document view, with no UI element available to exit this view.
  4. The only way to exit the view is to click View -> Back, or to reload/restart the app.
  5. The same behaviour can be observed in the browser. But there the browser Back button can be utilised.

Expected behavior:

  • Links in the above mentioned configuration behave the same as any other link:

    • In the app, a browser window containing the link content is opened
    • In the browser, a new tab is opened.
  • Also the document view should contain a visible exit button, that allows the user to easily exit the window.

Actual behavior:

The file is opened within the app or browser.

View.mp4

Server Setup Information:

  • Version of Rocket.Chat Server: 4.5.0
  • Operating System: Docker
  • Deployment Method: Docker
  • Number of Running Instances: 1
  • DB Replicaset Oplog: -
  • NodeJS Version: v14.18.3
  • MongoDB Version: 4.4.12 / wiredTiger (oplog Enabled)

Client Setup Information

  • Desktop App or Browser Version:
  • Browser: Chrome: Version 99.0.4844.51
  • App: Version 3.7.7
  • Operating System: MacOS 12.2.1

Additional context

Relevant logs:

Hey, I wanted to understand what the exact issue is, at the moment the pdf preview link opens up in the Rocket chat app itself and you could navigate back to Rocket Chat with CMD+[, could you please help me understanding what are the other issues with the pdf opening in the Rocket Chat app itself instead of the browser?

redRolf commented 2 years ago

@Palanikannan1437 Thank yo for following up on this issue, please excuse my late response. The problem is three fold:

  1. I would expect any link to behave the same way, as any other link. This means, that regardless of what a link points to the behaviour ist the same. This would mean the clicking on the link actually does what the user expects which is, that a browser tab is opened and what ever content is behind the link is displayed in the new browser tab.
  2. Normal users do not know more than a hand full of short cuts it is highly impractical to expect them to memorise a short cut for this edge case. Even I didn't know that shortcut. Also the shortcut CMD+[ is highly impractical on a non US Key map. For example on the Swiss Keyboard layout this would result in key press of the following keys: OPTION + SHIFT + CMD + 5 which I would not consider practical
  3. Not giving the user a clickable UI button in order to leave a view is just bad UI design in my opinion.

What I would like to see is that one of the following (or both) is implemented:

  1. A file view such as displaying a pdf has a clear back or exit button. Here is a mock up:

image

  1. All links behave the same way, the same action is triggered every time I click on a link, regardless of the resource behind the link. Otherwise it will appear as inkonsistent behaviour to the user.

I hope this helped in clarifying the issue. If you have more questions I will be happy to answer them :)

Palanikannan1437 commented 2 years ago

@Palanikannan1437 Thank yo for following up on this issue, please excuse my late response. The problem is three fold:

  1. I would expect any link to behave the same way, as any other link. This means, that regardless of what a link points to the behaviour ist the same. This would mean the clicking on the link actually does what the user expects which is, that a browser tab is opened and what ever content is behind the link is displayed in the new browser tab.
  2. Normal users do not know more than a hand full of short cuts it is highly impractical to expect them to memorise a short cut for this edge case. Even I didn't know that shortcut. Also the shortcut CMD+[ is highly impractical on a non US Key map. For example on the Swiss Keyboard layout this would result in key press of the following keys: OPTION + SHIFT + CMD + 5 which I would not consider practical
  3. Not giving the user a clickable UI button in order to leave a view is just bad UI design in my opinion.

What I would like to see is that one of the following (or both) is implemented:

  1. A file view such as displaying a pdf has a clear back or exit button. Here is a mock up:

image

  1. All links behave the same way, the same action is triggered every time I click on a link, regardless of the resource behind the link. Otherwise it will appear as inkonsistent behaviour to the user.

I hope this helped in clarifying the issue. If you have more questions I will be happy to answer them :)

@redRolf Thank you so much for taking the time and clarifying your issue in so much detail, all the points you stated make a lot of sense, I just wanted a good first issue to start with and this seems like an excellent one!

I'll start to implement the features you mentioned about asap and follow up with you!

PS: Thanks a ton for the mockup :p

jeanfbrito commented 2 years ago

We fixed the problem with Twitter links getting stuck on the Desktop app. Please update to version 3.8.11 that will have this fixed.