Clicking pane selector of selected type while staying in details view should return to add-on list

VERIFIED FIXED in mozilla1.9.3a5

Status

()

VERIFIED FIXED
8 years ago
8 years ago

People

(Reporter: KWierso, Assigned: bparr)

Tracking

Trunk
mozilla1.9.3a5
Points:
---
Bug Flags:
in-testsuite ?
in-litmus -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [AddonsRewriteTestday][rewrite])

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a5pre) Gecko/20100430 Minefield/3.7a5pre RTSE/1.2.0.20100406
Build Identifier: 

In the EM rewrite, if you're looking at a detailed view of an extension in the right column of the addon manager, clicking "Extensions" from the left column does nothing. It should (in my opinion) restore the full list of extensions, just like the "Back to Extensions" button at the top of the page.

If you chose some other item from the left column, and then reselect "Extensions", it will show the list of extensions, not the detailed view.

Reproducible: Always
(Reporter)

Updated

8 years ago
Whiteboard: [rewrite]
Keywords: uiwanted
OS: Windows 7 → All
Hardware: x86 → All
Summary: Clicking "Extensions" on the left while in details view on the right should show full list of addons. → Clicking pane selector of selected type while staying in details view should return to add-on list
Whiteboard: [rewrite] → [AddonsRewriteTestday][rewrite]
Version: unspecified → Trunk
Spoke with Boriss over IRC, we should do this.
Keywords: uiwanted
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Updated

8 years ago
Assignee: nobody → bparr
(Assignee)

Comment 2

8 years ago
Created attachment 446095 [details] [diff] [review]
Simple patch by adding a click event listener
Attachment #446095 - Flags: review?(dtownsend)
Comment on attachment 446095 [details] [diff] [review]
Simple patch by adding a click event listener

This is great work and does fix the bug. There is one minor change that you should do to improve this. Once you've done that, re-attach the patch and we can get it checked in.

>+    this.node.addEventListener("click", function(aEvent) {
>+      var selectedItem = self.node.selectedItem;
>+      if (aEvent.target.localName == "richlistitem" &&
>+          aEvent.target.id == selectedItem.id) {

Here there is no need to compare the ID of the elements, instead you should just compare that event.target == selectedItem.
Attachment #446095 - Flags: review?(dtownsend) → review+
(Assignee)

Comment 4

8 years ago
Created attachment 446307 [details] [diff] [review]
Updated patch

Included Mossop's change.
Attachment #446095 - Attachment is obsolete: true
Attachment #446307 - Flags: review?(dtownsend)
Comment on attachment 446307 [details] [diff] [review]
Updated patch

Perfect, thanks
Attachment #446307 - Flags: review?(dtownsend) → review+
(Assignee)

Updated

8 years ago
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a5
Landed as http://hg.mozilla.org/mozilla-central/rev/009a59650292
Flags: in-testsuite?
Flags: in-litmus?
Verified with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a5pre) Gecko/20100526 Minefield/3.7a5pre

This is testable by an automated test. Blair, would that invalidate the in-litmus flag?
Status: RESOLVED → VERIFIED
Flags: in-litmus? → in-litmus-
You need to log in before you can comment on or make changes to this bug.