Affected versions:

70.0a1 (2019-08-01)

Affected platforms:

ALL

Steps:

1. Open FF and access: https://soundcloud.com/
2. Play a random song.
3. Click anywhere on the seekbar to forward and backward the song multiple times.

Expected result:

The user should be able to jump to a specific time of the song without issue by clicking anywhere on the seekbar.

Actual result:

Seekbar jumps when the user tries to jumps to a specific time.

*Attached a screen recording with the issue.

[Regression-Range]:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d497a1f58d27d75da3667e74a5a7efe5799119fd&tochange=46b354546ad842b72f02a025126dfedcc38e5ad0

Andreas based on the regression rage this was most likely cause by bug 1561254 or bug 1493613. Could you please have a look?

[Tracking Requested - why for this release]:
P1 - Soundcloud is broken

(In reply to Nils Ohlmeier [:drno] from comment #1)

Andreas based on the regression rage this was most likely cause by bug 1561254 or bug 1493613. Could you please have a look?

Bug 1561254 causing this is just impossible. Bug 1493613 is very likely.

This hasn't been needed since the last larger refactor of DecodedStream
(bug 1423241), but got incorporated wrongly with bug 1493613.

When DecodedStream is Stop()ed and then Start()ed, mStartTime is set to the
starting position, i.e., the seeked position in case of a seek or 0 if decoding
from the start of a file, and a track is added to the graph with a playout
position starting at 0. The reported position by DecodedStream should then be
mStartTime plus the last reported output time of the tracks.

mStreamTimeOffset was offseting this further, so DecodedStream was reporting a
too large number.

https://hg.mozilla.org/mozilla-central/rev/1870efc7be2b

Verified - Fixed on latest Nightly 70.0a1 (2019-08-05) on Windows 10, Ubuntu 18.04 and Mac OS 10.14.