-
-
Notifications
You must be signed in to change notification settings - Fork 833
Do not preload encrypted videos|images unless autoplay or thumbnailing is on #5352
Conversation
A surprise along the way, turns out that |
Yes! |
Does this not also apply to images and other media? This is how my friend encountered this issue, via images, not video preloads. |
This needs to be done for images and audio too. |
Latest change includes the same treatment for images, where images will not download IF the user has disabled thumbnailing. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this does the right thing?
this.setState({ | ||
error: "No file given in content", | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this could be collapsed to just 1 line, but it ultimately is personal preference.
This is great. I really appreciate you fixing this, because my internet connection is absolutely awful, which means whenever someone sent large media it just got completely trashed without any way to fix it other than to stop using matrix. One thing I'm confused about: what exactly is thumbnailing? What functionality do I miss out on by disabling it? |
It's just a smaller version of an image/video to represent it. It should happen automatically in the background. #element-web:matrix.org is a better place to ask for support. |
const content = this.props.mxEvent.getContent(); | ||
if (!content.file) { | ||
this.setState({ | ||
error: "No file given in content", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this not be i18n'd?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good point. I'd be happy for a commit to fix it to land directly on develop
For Chrome-based browsers, it seems we need to set some non-empty `src` URI for the video element's play button to be enabled, so this crafts an empty `data` URI and ensures playing is triggered once the real content has been fetched. Fixes element-hq/element-web#15694 Regressed by #5352
For Chrome-based browsers, it seems we need to set some non-empty `src` URI for the video element's play button to be enabled, so this crafts an empty `data` URI and ensures playing is triggered once the real content has been fetched. Fixes element-hq/element-web#15694 Regressed by #5352
partially fixes element-hq/element-web#6710
(The first commit typescriptify's
MVideoBody
)This changes
MVideoBody
so that the file is not immediately downloaded & decrypted in the browser when the element is first shown. Instead, the user must click play on the video player. This should be mostly seamless aside from the incorrect timestamp on the video player.Preview: