Page MenuHomePhabricator

[web][native] update `InputStateContainer` logic for sending multimedia messages
ClosedPublic

Authored by kamil on Sep 13 2024, 4:27 AM.
Tags
None
Referenced Files
F3522702: D13332.id44213.diff
Mon, Dec 23, 7:22 AM
F3521086: D13332.diff
Mon, Dec 23, 2:19 AM
Unknown Object (File)
Mon, Dec 16, 5:10 AM
Unknown Object (File)
Sun, Nov 24, 2:01 PM
Unknown Object (File)
Nov 20 2024, 11:08 AM
Unknown Object (File)
Nov 20 2024, 11:08 AM
Unknown Object (File)
Nov 14 2024, 1:02 PM
Unknown Object (File)
Nov 14 2024, 12:59 PM
Subscribers

Details

Summary

ENG-8424.

This makes updates code to use one hok on both platforms which handles both thick and thin threads, avoids hacking logic on both InputStateContainer.

Depends on D13331

Test Plan
  1. Sending multimedia.
  2. Multimedia statuses.
  3. Multimedia retries.
  4. Creating thread where first message is multimedia.

Diff Detail

Repository
rCOMM Comm
Branch
publish
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

kamil held this revision as a draft.
kamil published this revision for review.Sep 13 2024, 4:42 AM
bartek added inline comments.
web/input/input-state-container.react.js
540–543

Is this still used anywhere in this func? I see you moved this into the useInputStateContainerSendMultimediaMessage() hook in the previous diff

This revision is now accepted and ready to land.Sep 13 2024, 6:19 AM
tomek added inline comments.
web/input/input-state-container.react.js
548

What does it mean to be a legacy? Are we planning to update the approach?

web/input/input-state-container.react.js
548

We have two ways of calling the create_multimedia_message keyserver endpoint:

  • the new one which accepts mediaMessageContents - used on native, according to D5127 and D5191 it also supports videos
  • the "legacy" one which accepts mediaIDs - used on web

I guess we'll stop using the legacy one when we implement video uploads for web