1350388 - Drag&drop some HTTPS links in the download icon displays wrongly download as failed

Status: VERIFIED FIXED

(Firefox :: Downloads Panel, defect)

Description

[Loic]

Attachment: failed-ddl-FF55.jpg

STR:

1) Open https://bugzilla.mozilla.org/
2) Wait for ~10 sec (it's empirical but I only found that to reproduce the issue consistently)
3) Drag&drop the link "Bugzilla@Mozilla" (upper left corner) in the download icon in the toolbar

Result: the download panel displays the yellow mark for "download failed" even if the file has been really downloaded (visible on the disk).

Regression range:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=5ae59bdcd2d4f9617d6663ab823b4a384fdd6204&tochange=08df0e07f0ba02a27e532b25a0d3415166a6bba1

Dragana Damjanovic — Bug 1343600 - add TLS handshake Start/Stop events. r=:valentin

Comment 1

[Dragana Damjanovic [:dragana]]

Attachment: bug_1350388_v1.patch

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/f129d307ce4b
NS_NET_STATUS_TLS_HANDSHAKE_STARTING/ENDED is not an error for nsWebBrowserPersist. r=valentin

Comment 3

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/f129d307ce4b

Comment 4

[Marcia Knous [:marcia]]

Tracking 54/55+ for this regression.

Comment 5

[Dragana Damjanovic [:dragana]]

Comment on attachment 8852060 [details] [diff] [review]
bug_1350388_v1.patch

Approval Request Comment
[Feature/Bug causing the regression]: Bug 1343600
[User impact if declined]: Downloads can be mark as failed, because nsWebBrowserPersist interpret new transport events  NS_NET_STATUS_TLS_HANDSHAKE_STARTING/ENDED as an error.
[Is this code covered by automated tests?]: no
[Has the fix been verified in Nightly?]: yes
[Needs manual test from QE? If yes, steps to reproduce]: there are step to reproduce in comment #0
[List of other uplifts needed for the feature/fix]:none
[Is the change risky?]:none
[Why is the change risky/not risky?]: just add 2 additional transport status events to the list.
[String changes made/needed]:none

Comment 6

[Julien Cristau [:jcristau]]

Comment on attachment 8852060 [details] [diff] [review]
bug_1350388_v1.patch

regression fix for aurora54

Comment 7

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/4a9388153442

Comment 8

[Saheda Reza [:Antora]]

I have successfully reproduced this bug on firefox nightly according to(2017-03-24)

Fixing bug is verified on Latest Developer Edition-- Build ID : (20170402004002),User Agent: Mozilla/5.0 (Windows NT 10.0; rv:54.0) Gecko/20100101 Firefox/54.0

Tested OS -- Windows10 32bit

[bugday-20170329]

Comment 9

[balaji2198]

The issue is no longer reproducible on Firefox 55.0a1 (2017-04-03)
OS:windows 7(32 bit)

[bugday-20170405]

Comment 10

[Shubhendra Singh Chauhan]

[bugday-20170412]

The issue is no longer reproducible on Firefox Nightly 55.0a1.
Tests were performed under Windows 10x64.

Comment 11

[sriramsubramanian23]

[bugday-20170419]

Status: FIXED & VERIFIED.
Browser: Mozilla/5.0 (X11; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0

The issue is no longer reproducible on Firefox Aurora 
Tests were performed under Ubuntu 15.10 x64.

Comment 12

[Cristian Comorasu, QA [:ccomorasu], Releae Desktop QA - Please contact [e-mail]]

I reproduced this issue with Fx 55.0a1 (24-03-2017) on Windows 7 x64.
I can confirm this issue is fixed I verified using Fx 55.0a1 (20170424030211) and Fx 54.0b1 on Windows 7 x64.

Cheers!

Comment 13

[u576612]

The issue is no longer reproducible on Firefox 52.0.2 (2017-04-03)
OS: macOS Sierra 10.12.3

[bugday-20170405]