Closed
Bug 822689
Opened 12 years ago
Closed 12 years ago
Nothing happens when clicking on a complete download in the Downloads Panel
Categories
(Firefox :: Downloads Panel, defect)
Firefox
Downloads Panel
Tracking
()
RESOLVED
FIXED
Firefox 20
People
(Reporter: sbadau, Assigned: mak)
References
Details
(Keywords: regression)
Attachments
(1 file)
(deleted),
patch
|
mconley
:
review+
|
Details | Diff | Splinter Review |
Mozilla/5.0 (Windows NT 6.1; rv:20.0) Gecko/20121218 Firefox/20.0
Build ID: 20121218030803
Prerequisites: Firefox is set as the default browser.
Steps to reproduce:
1. Launch Firefox
2. Navigate to http://www.mozilla.org/en-US/ and save the page
3. After the download is completed open the Downloads Panel and click on it.
Expected results:
A new tab with http://www.mozilla.org/en-US/ is opened.
Actual results:
Nothing happens.
Note: This is not reproducible on a Nightly build from December 17th.
Assignee | ||
Comment 1•12 years ago
|
||
I have a patch for this.
Assignee: nobody → mak77
Blocks: ReleaseDownloadsPane, 675902
Status: NEW → ASSIGNED
Keywords: regression
Assignee | ||
Comment 2•12 years ago
|
||
Attachment #693433 -
Flags: review?(mconley)
Comment 3•12 years ago
|
||
Comment on attachment 693433 [details] [diff] [review]
patch v1.0
Review of attachment 693433 [details] [diff] [review]:
-----------------------------------------------------------------
Good catch!
Attachment #693433 -
Flags: review?(mconley) → review+
Assignee | ||
Comment 4•12 years ago
|
||
Target Milestone: --- → Firefox 20
Assignee | ||
Updated•12 years ago
|
Summary: Nothing happens when clicking on a compete download in the Downloads Panel → Nothing happens when clicking on a complete download in the Downloads Panel
Comment 5•12 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Do we have coverage for this regression in testsuite?
Flags: in-testsuite?
Assignee | ||
Comment 8•12 years ago
|
||
nope, the current testsuite for the panel is quite limited, we need more automated tests once the feature stops being a moving target.
(In reply to Marco Bonardo [:mak] (intermittently avail. until 3 Jan) from comment #8)
> nope, the current testsuite for the panel is quite limited, we need more
> automated tests once the feature stops being a moving target.
Regardless of the release this ships in, why would we not have a test checking this in the latest Nightly builds?
Assignee | ||
Comment 10•12 years ago
|
||
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #9)
> Regardless of the release this ships in, why would we not have a test
> checking this in the latest Nightly builds?
The cost is non-trivial. The interaction and panel contents changed so many times we would have rewritten it 10 times by now. And it's not trivial to make (non-fragile and intermittently orange) tests interacting with panel buttons opening external resources.
I'm not saying I'd not love to have these tests right now, but considered the limited time and resources we have, getting that right would delay the feature by one, maybe 2 releases.
Comment 11•12 years ago
|
||
Okay, thanks for helping me understand the situation, Marco. I agree that it would not make sense to make an automated test which will be prone to failure due to code churn.
Simona, since you are QA lead for this feature I will trust you to continue to check this manually at least once before each merge. At least until we have an automated test covering this.
QA Contact: simona.marcu
You need to log in
before you can comment on or make changes to this bug.
Description
•