Closed Bug 1553537 Opened 5 years ago Closed 5 years ago

The installation process is automatically closed after clicking the "x" button while having a slow Internet connection

Categories

(Firefox :: Installer, defect, P1)

Unspecified
Windows 10
defect

Tracking

()

VERIFIED FIXED
Firefox 69
Tracking Status
firefox67 --- wontfix
firefox67.0.1 --- wontfix
firefox68 --- wontfix
firefox69 --- verified

People

(Reporter: remus.dranca, Assigned: mhowell)

References

Details

Attachments

(3 files)

Attached image close.gif (deleted) —

[Affected versions]:

  • Firefox Release 66.0.5 and above

[Affected Platforms]:

  • Windows 10

[Prerequisites]:

  • Have Stub installer downloaded on your PC.
  • Have NetLimiter 4 installed and opened in order to simulate a slow Internet connection.

[Steps to reproduce]:

  1. Run the Stub installer from prerequisites.
  2. Click "Yes" on the UAC prompt.
  3. Quickly check the first checkbox from the NetLimiter/DL Limit(5kb/s) section.
  4. Click the "x" close button from the Firefox installation prompt window.
  5. Observe the behavior.

[Expected result]:

  • The "Do you want to install Firefox" prompt is displayed and remains open along with the installation prompt.

[Actual result]:

  • The "Do you want to install Firefox" prompt is briefly displayed and both both prompts are automatically closed.

[Notes]:

  • I was able to verify this issue only on Windows 10. I will follow up tomorrow with a comment after I will test it on other Windows platforms.
  • Attached is a screen recording of the issue.
Priority: -- → P3

I retested this issue and it's not reproducible on Windows 7x64; Windows 8x64 and Windows 8.1 x32 platforms. It's only reproducible on Windows 10.

This is a crash that's being caused by our InetBgDL plugin, which is the code that interfaces with the Microsoft WinInet library to handle the file download. We process the file transfer in 256 KiB chunks, and if it takes a long time to receive one chunk, we simply terminate the thread responsible for handling the file transfer without properly shutting down the transfer. That means WinInet is still running and downloading data, and when it goes to write that data into the buffer we supplied, that buffer is located on the stack of a thread which has now been terminated, so the result of trying to write there is a crash.
The solution then is just to properly close the connection before terminating the thread.

Assignee: nobody → mhowell
Status: NEW → ASSIGNED
Priority: P3 → P1

I'm also going to switch InetBgDL to a Visual Studio 2019 solution, because having to spin up VC++ 6 just to compile NSIS plugins is for the birds.

Also reduce the timeout for terminating the thread to 5 seconds, because 10
seconds is too long to be completely hanging the UI.

Matt, did this ever land?

Flags: needinfo?(mhowell)

No, the review for it isn't done yet.

Flags: needinfo?(mhowell)
Pushed by mhowell@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/98db541275e5 Part 1 - Close our WinInet handles before terminating the file transfer thread. r=agashlin
Pushed by mhowell@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/0d31da2473ba Part 2 - Port the InetBgDL plugin to Visual Studio 2019. r=agashlin

I have verified this issue and it's no longer reproducible with the latest Firefox Nightly Installer 69.0a1 (Build ID: 20190704214457), downloaded from the latest-mozilla-central.
Tested on 2 different machines with Windows 10 x64.

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

Attachment

General

Created:
Updated:
Size: