407541 - Details pane in Library shows wrong info when a history item is selected

Status: VERIFIED FIXED

(Firefox :: Bookmarks & History, defect, P2)

Description

[Tony Chung [:tchung]]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b2pre) Gecko/2007120804 Minefield/3.0b2pre
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b2pre) Gecko/2007120804 Minefield/3.0b2pre

The Most Visited URLs in the places Organizer > Most Visited window do not show the properties of the URLs at all.  

Reproducible: Always

Steps to Reproduce:
1. Install trunk nightly, and Visit a few different URLs
2. Open places organizer > Bookmarks Toolbar > Smart Bookmarks > Most Visited folder
3. Click on any of the most visited URLs in the window, and verify the properties window beneath do not display the corresponding url information.

** See screenshot
Actual Results:  
No Properites window

Expected Results:  
Properties for the associated URLs selected

Comment 1

[Tony Chung [:tchung]]

Attachment: No Properties window screenshot

Comment 2

[Carsten Book [:Tomcat]]

Attachment: leopard

on leopard a url is displayed, but its the wrong url to the bookmark (is this a new issue?)

Build Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b2pre) Gecko/2007120804 Minefield/3.0b2pre

Comment 3

[Carsten Book [:Tomcat]]

Attachment: better leopard screenshot

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+2]]

If you open the Organizer and directly go to "Most Visited" the bookmarks properties aren't shown as Tony stated. I can see the same with the latest nightly.

But Carsten is also right. It's simple to reproduce. Just click on any other bookmark so its properties are displayed. Now the same properties are visible for each of the bookmarks listed under "Most Visited".

Comment 5

[Marco Bonardo [:mak]]

it's always the same bug, most visited is a history query, so itemId (the bookmark id) = -1, see also Bug 407872, Bug 407612, Bug 407614. 

Comment 7

[Alex Faaborg [:faaborg] (Firefox UX)]

The behavior should be the same as any other bookmark.  Removing uiwanted keyword, please add it back if you need more direction.

Comment 8

[Asaf Romano (gone)]

Adding it back, urls under this query are history entries, not bookmarks.

Comment 9

[Mike Connor [:mconnor]]

Not blocking on this bug for final ship. Would take a safe enough patch if one comes through.

Comment 10

[Henrik Skupin [:whimboo][⌚️UTC+2]]

In my opinion and after having some tests I don't think that minusing blocking-firefox3 is the right decision here. As the former title said it happens for the "Most Visited" entry. But it will be more visible when opening the "History" folder within the Library. If you select each of the listed bookmarks, the details pane is grayed-out and the visible content is from the latest selected bookmark.

This is something which a lot of people will recognize when browsing the history within the Library.

Mconnor, it would be great if you could reconsider your decision based on my comment. Any change to get the flag blocking-firefox3 back?

Comment 11

[Henrik Skupin [:whimboo][⌚️UTC+2]]

I have to re-ask blocking-firefox3. All users will be affected by this bug when going to "History | Show All History". The details deck doesn't work at all and the reported issue will be visible obviously.

Comment 12

[Mike Beltzner [:beltzner, not reading bugmail]]

Yeah, this needs to block. The current behaviour is pretty confusing.

As for UI direction, when a history item is selected, the following information should be shown as read-only fields:

 - name = page title
 - location = location
 - no tags field or empty tags field (not sure that I care here, whatever's easier)

Comment 13

[Ria Klaassen (not reading all bugmail)]

Is this the same as bug 423958?

Comment 15

[Marco Bonardo [:mak]]

(In reply to comment #13)
> Is this the same as bug 423958?

yes, tnx

Comment 16

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to comment #15)
> > Is this the same as bug 423958?
> 
> yes, tnx

Sure? I would have said its a dupe of bug 423924.

Comment 17

[Marco Bonardo [:mak]]

(In reply to comment #16)
> Sure? I would have said its a dupe of bug 423924.

that is more specific to some widget (dropmarkers/folder menulist), while in bug 423958 the user talk about "buttons, drop down menus, input areas", specifying "seems there should be nothing at all at that place", so IMO it's clear that the expected behaviour is more similar to this. Whatever it will be the solution to both would be unified since is "hide the pane or show correct infos"

Comment 18

[cris]

I reported 423958

I really have no idea of what the intension of that design is. so don't read too much into my guess.

most obvious problem. like my old attachment in 423598. is that the UI is obviously broken(graphically first, functionally second). that's 100 percent a blocker.

also, I think whenever some item (history, bookmark) is selected. the info should be displayed, and editable.

Comment 19

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to comment #18)
> most obvious problem. like my old attachment in 423598. is that the UI is
> obviously broken(graphically first, functionally second). that's 100 percent a
> blocker.

The visually broken UI is already covered by bug 423924. The latter one will be fixed with a patch on this bug.

Comment 20

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to comment #19)
> The visually broken UI is already covered by bug 423924. The latter one will be
> fixed with a patch on this bug.

Sorry, I meant bug 415824.

Comment 21

[Asaf Romano (gone)]

Attachment: patch

Comment 22

[Mike Connor [:mconnor]]

Comment on attachment 316727 [details] [diff] [review]
patch

r+a=me, I wish this code was a little less messy, but that's what it is.

Comment 23

[Asaf Romano (gone)]

mozilla/browser/components/places/content/editBookmarkOverlay.js 1.42
mozilla/browser/components/places/content/places.js 1.156

Comment 24

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Verified with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008041804 Minefield/3.0pre

Comment 25

[Gervase Markham [:gerv]]

Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h".

In Thunderbird 3.0b, you do that as follows:
Tools | Message Filters
Make sure the correct account is selected. Click "New"
Conditions: Body   contains   places-to-b-and-h
Change the action to "Delete Message".
Select "Manually Run" from the dropdown at the top.
Click OK.

Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter.

Gerv