Closed Bug 1747402 Opened 11 months ago Closed 10 months ago

Open download when completed can display negative time

Categories

(Toolkit :: Downloads API, defect, P3)

Firefox 97
All
Linux
defect

Tracking

()

VERIFIED FIXED
98 Branch
Tracking Status
firefox-esr91 --- unaffected
firefox95 --- disabled
firefox96 --- disabled
firefox97 --- wontfix
firefox98 --- verified

People

(Reporter: phorea, Assigned: kabakert, Mentored)

References

(Blocks 1 open bug)

Details

(Keywords: good-first-bug)

Attachments

(2 files)

Note

  • Intermittently reproduced on a WI-FI connection

Affected versions

  • Nightly 97.0a1 2021-12-22

Affected platforms

  • Ubuntu 21.04 Wayland

Steps to reproduce

  1. Start any lengthier download, e.g: https://speed.hetzner.de/
  2. Before the download is complete, click on the ongoing download so that the elapsed time is replaced with Opening in ...
  3. Wait for the download to complete and check the elapsed time

Expected result

  • Either display Opening in 0s... longer or change with Opening in a few seconds as for regular download

Actual result

  • Opening in -1s... can be spotted right before the file is opened

Additional notes

  • We didn't encounter this on Windows 10, even with a network limiter

This component may be a better fit, please feel free to revert.

Component: Downloads Panel → Downloads API
Product: Firefox → Toolkit

I'm not sure how we end up with negative time values here. I suspect if we want to fix the root issue for this we'd want to take a look at getTimeLeft.

But we do have a string for handling odd values for an ongoing download: Opening when completed…. This is probably what we want to use. For a quick fix, we can add another check for when the time value is less than zero here.

Mentor: mtigley
Keywords: good-first-bug
Priority: -- → P3
Assignee: nobody → kabakert
Status: NEW → ASSIGNED
Pushed by mtigley@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/fd384d84f3d0
Added check for when time value is less than zero in getFormattedTimeStatus. r=mtigley
Status: ASSIGNED → RESOLVED
Closed: 10 months ago
Resolution: --- → FIXED
Target Milestone: --- → 98 Branch

The patch landed in nightly and beta is affected.
:kabakert, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Flags: needinfo?(kabakert)
Flags: needinfo?(kabakert)
Resolution: FIXED → WONTFIX
Resolution: WONTFIX → FIXED

This issue is no longer reproducible on latest Nightly 98.0a1 2022-01-27.

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.