Closed Bug 524090 Opened 12 years ago Closed 12 years ago

The list box does not scroll to show a selected address when i execute "View Image Info" in context menu

Categories

(Firefox :: Page Info Window, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
Firefox 3.7a1
Tracking Status
status1.9.2 --- beta3-fixed

People

(Reporter: alice0775, Assigned: mozilla.bugs)

References

()

Details

(Keywords: verified1.9.2)

Attachments

(1 file, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2b2pre) Gecko/20091022 Firefox/3.5.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a1pre) Gecko/20091022 Minefield/3.7a1pre ID:20091022234402

In the web page where many images are displayed,
The list box does not scroll to show a selected address when i execute "View Image Info" in context menu.

Reproducible: Always

Steps to Reproduce:
1.Start Minefield with new profile
2.OPEN URL
3.Right-click on Minefiled Image Icon in Congratulations! section.
4. Select "View Image Info"
Actual Results:  
Page info Window opened. However the listbox does not scroll to show the selected address.

Expected Results:  
The list box must scroll automatically to show the selected address
Blocks: 517902
Version: unspecified → Trunk
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows Vista → All
Hardware: x86 → All
Component: Menus → Page Info
QA Contact: menus → page.info
I think the image should also be focused in the list; currently the focus appears to be on the first tab, so hitting DOWN doesn't do anything since that moves focus to the currently selected tab. Hitting DOWN again then moves to the Permissions tab.
(In reply to comment #1)
> I think the image should also be focused in the list; currently the focus
> appears to be on the first tab, so hitting DOWN doesn't do anything since that
> moves focus to the currently selected tab. Hitting DOWN again then moves to the
> Permissions tab.

My question would be should that be the default behavior if the media tab is selected or only when "View Image Info" function is selected.  If the former, we should probably file another bug for it.

I am curious why the browser still functions as if the general tab is selected while the media tab is shown and focused.
I'd say only for the latter (when View Image Info is used). If I have the Page Info dialog open and select the media tab, then the tab should have focus since that is what I selected.

In the case of View Image Info, my desire was to view the information about the specific image, so it should have focus.
Assigning to me.
Assignee: nobody → mozilla.bugs
Status: NEW → ASSIGNED
Attached patch Patch using ensureRowIsVisible (obsolete) — Splinter Review
This patch scrolls the tree using ensureRowIsVisible, and then it focuses the tree only if the "View Image Info" arguments are passed to the window.

I don't necessarily like the fact that ensureRowIsVisible() loads the element at the bottom of the view, I would prefer it loading at the top; however the alternative of using scrollToRow() forces the item to always be on top even if it means scrolling past the end of the tree.  FWIW, the former is used more often than the latter.

Dao: Which is better in your opinion?
Attachment #410712 - Flags: review?(dao)
Comment on attachment 410712 [details] [diff] [review]
Patch using ensureRowIsVisible

>+  var boxObject = tree.boxObject.QueryInterface(Components.interfaces.nsITreeBoxObject);
>   for (var i = 0; i < tree.view.rowCount; i++) {
>     if (gImageElement == gImageView.data[i][COL_IMAGE_NODE]) {
>       tree.view.selection.select(i);
>+      boxObject.ensureRowIsVisible(i);

tree.treeBoxObject.ensureRowIsVisible(i);
Attachment #410712 - Flags: review?(dao) → review+
Attached patch Patch v 1.1Splinter Review
Change made.
Attachment #410712 - Attachment is obsolete: true
Keywords: checkin-needed
Attachment #410982 - Flags: approval1.9.2?
thanks!

http://hg.mozilla.org/mozilla-central/rev/9e8abf3adb4c
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.7a1
This works great, nice polish for this feature!  Thanks Tanner!
Verified Fixed.

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a1pre) Gecko/20091110 Minefield/3.7a1pre (.NET CLR 3.5.30729) ID:20091110052734
Status: RESOLVED → VERIFIED
Comment on attachment 410982 [details] [diff] [review]
Patch v 1.1

a192=beltzner.

It'd be good to add a test for this, but not critical.
Attachment #410982 - Flags: approval1.9.2? → approval1.9.2+
Keywords: checkin-needed
Verified on 1.9.2 with build on all platforms like Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2b3pre) Gecko/20091114 Namoroka/3.6b3pre ID:20091114033807
Flags: in-testsuite?
Keywords: verified1.9.2
You need to log in before you can comment on or make changes to this bug.