Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Media files not played on google chrome #2246

Closed
nlko opened this issue Aug 24, 2024 · 2 comments
Closed

Media files not played on google chrome #2246

nlko opened this issue Aug 24, 2024 · 2 comments
Assignees
Labels
area/screen/files Issues related to Files screen effort/hours Estimated to take one or several hours exp/novice Someone with a little familiarity can pick up kind/bug A bug in existing code (including security flaws) P1 High: Likely tackled by core team if no one steps up

Comments

@nlko
Copy link

nlko commented Aug 24, 2024

Describe the bug

I'm using the latest google chrome and the media files are not playable/viewable. (same problem on brave it seems)

However, I noticed that

  • Files are playable when accessible from the local gateway;
  • Files are playable when accessed with the ipfs-desktop application;
  • Files are playable when accessed with the webui using firefox.

To Reproduce
Steps to reproduce the behavior:

  1. Open the chrome browser
  2. Navigate to webui.ipfs.io
  3. In the files section click on a media file (image, audio or video)
  4. The file is not accessible from the webui (broken link icon is displayed for images or the play button is greyed out for audio or video files)

Expected behavior
Files should be playable in chrome.

Screenshots

For images (broken link icon):
image

For audio/videos (play button stays greyd out):
image

Desktop (please complete the following information):

  • OS: Ubuntu 22.04
  • Browser google chrome : Versión 128.0.6613.84 (Build oficial) (64 bits)
  • ipfs version 0.29.0

Additional context

@nlko nlko added the need/triage Needs initial labeling and prioritization label Aug 24, 2024
@lidel
Copy link
Member

lidel commented Aug 30, 2024

Thank you for reporting this.

I was able to reproduce it, but it occurs only on non-local origins like https://webui.ipfs.io because the protocol of localhost gateway gets upgraded to https for some reason:

2024-08-30_21-15_1

There is no TLS on localhost, and that produces error:

2024-08-30_21-15

There is a message which suggests Chrome started force-upgrading URLs to https a while ago:

2024-08-30_21-39

But this should not happen to localhost URLs which are a secure context already. Possibly, this is a new regression specific to localhost.

Note that Kubo had subdomain gateway, so http://locahost:8080/ipfs/cid will redirect to http://cid.ipfs.localhost:8080 – perhaps subdomains are not interpreted as secure context correctly and that triggers forced upgrade to https. switching to IP should help.

@nlko A workaround until this is fixed is to use webui provided by Kubo on the RPC port itself: http://127.0.0.1:5001/webui/

@lidel lidel added kind/bug A bug in existing code (including security flaws) exp/novice Someone with a little familiarity can pick up P1 High: Likely tackled by core team if no one steps up area/screen/files Issues related to Files screen effort/hours Estimated to take one or several hours and removed need/triage Needs initial labeling and prioritization labels Aug 30, 2024
@lidel lidel self-assigned this Aug 30, 2024
lidel added a commit that referenced this issue Aug 30, 2024
this aims to sanitize localhost src url for embedded image/audio/video
to avoid mixed-content warning in latest chrome-based browsers

Rationale:
#2246 (comment)
lidel added a commit that referenced this issue Aug 30, 2024
this aims to sanitize localhost src url for embedded image/audio/video
to avoid mixed-content warning in latest chrome-based browsers

Rationale:
#2246 (comment)
lidel added a commit that referenced this issue Aug 30, 2024
this aims to sanitize localhost src url for embedded image/audio/video
to avoid mixed-content warning in latest chrome-based browsers

Rationale:
#2246 (comment)
@lidel
Copy link
Member

lidel commented Aug 30, 2024

Confirmed this was fixed in #2253
You can use https://dev.webui.ipfs.io/ until a new release is cut next week.

@lidel lidel closed this as completed Aug 30, 2024
ipfs-gui-bot pushed a commit that referenced this issue Sep 23, 2024
## [4.3.1](v4.3.0...v4.3.1) (2024-09-23)

 CID `bafybeideglc722hiwhsy4kiyl2fivf5lr6wozy2iuixtgzkvl3v4hasaty`

 ---

### Bug Fixes

* **file-preview:** safeSubresourceGwUrl ([#2253](#2253)) ([bb861a3](bb861a3)), closes [/github.com//issues/2246#issuecomment-2322192398](https://github.com/ipfs//github.com/ipfs/ipfs-webui/issues/2246/issues/issuecomment-2322192398)
* **files:** avoid duplicated fetch during preview ([#2254](#2254)) ([eefae25](eefae25)), closes [#2217](#2217)
* **files:** prefer subdomain gw in copied share links ([#2255](#2255)) ([e8c4421](e8c4421))

### Trivial Changes

* .io → .tech ([b9f622d](b9f622d))
* browserslist@latest ([#2251](#2251)) ([809c55a](809c55a))
* Pull transifex translations ([#2258](#2258)) ([2250374](2250374))
* use ipld-explorer-components@7.0.2 ([#2257](#2257)) ([99ba9ac](99ba9ac))
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/screen/files Issues related to Files screen effort/hours Estimated to take one or several hours exp/novice Someone with a little familiarity can pick up kind/bug A bug in existing code (including security flaws) P1 High: Likely tackled by core team if no one steps up
Projects
No open projects
Status: No status
Development

No branches or pull requests

2 participants