Closed Bug 595570 Opened 9 years ago Closed 9 years ago

Bookmark Sidebar no longer shows the Bookmark title when you hover over a link

Categories

(Core :: XUL, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- final+

People

(Reporter: Event.H04iz0n, Assigned: neil)

References

Details

(Keywords: regression)

Attachments

(2 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0b6pre) Gecko/20100911 Firefox/4.0b6pre
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b6pre) Gecko/20100911 Firefox/4.0b6pre

With the latest build (Mozilla/5.0 (Windows NT 5.1; rv:2.0b6pre) Gecko/20100911 Firefox/4.0b6pre ID:20100911041541):
The Bookmark Sidebar no longer shows the Bookmark title when you hover over a link.

Was working with previous builds.

Reproducible: Always

Steps to Reproduce:
1. Open Bookmark Sidebar
2. Move the Mouse pointer over a Link
3. Link title no longer displays.
Actual Results:  
Link title does not display.

Expected Results:  
Link title displays, like it still does when hovering over a Link in the Bookmarks Toolbar.
As seen in example, without a title it is impossible to tell which 'The Off... [icial Win32 ???? Trunk build is (or; is not yet) out]'.

Additional information about Sidebar use:
 I use the Sidebar most often since it remembers which Folders were open last time I used it and where I was in them.
 The other methods 'Show Bookmarks' even 'Bookmarks Toolbar' I have to drill down through my folders (often from 3 to 5 levels deep)...

 I use the Sidebar to select/maintain (Add/Delete) my Bookmarks.
 And if I am doing major reorganization of my Bookmark Folders/Links structure I will most often use the Sidebar along with 'Show all Bookmarks'.
Keywords: regression
OS: Windows XP → All
Hardware: x86 → All
Target Milestone: --- → Firefox 4.0
Version: unspecified → Trunk
Seeing this as well. Possibly bug 588070?
Status: UNCONFIRMED → NEW
blocking2.0: --- → ?
Ever confirmed: true
I comfirme in local build that the changeset e6086627037c og buf 588070 causes the problem.
Blocks: 588070
blocking2.0: ? → ---
blocking2.0: --- → ?
Since we can't use a mouse event in this case, this was the easiest way I could find of propagating the coordinates to the popup showing event.
Assignee: nobody → neil
Status: NEW → ASSIGNED
Attachment #474520 - Flags: review?(enndeakin)
Component: Bookmarks & History → XUL
Product: Firefox → Core
QA Contact: bookmarks → xptoolkit.widgets
Target Milestone: Firefox 4.0 → ---
Comment on attachment 474520 [details] [diff] [review]
Set coordinates for tooltip event

Why is the first part of the patch there? Wasn't that the old version of the patch for bug 588070?
(In reply to comment #6)
> (From update of attachment 474520 [details] [diff] [review])
> Why is the first part of the patch there? Wasn't that the old version of the
> patch for bug 588070?
Absolutely correct, that junk doesn't belong there at all. Before I attach a revised patch, do you agree with the approach?
Seems OK to me.
Attachment #474520 - Attachment is obsolete: true
Attachment #475234 - Flags: review?(enndeakin)
Attachment #474520 - Flags: review?(enndeakin)
Comment on attachment 475234 [details] [diff] [review]
Without extraneous hunk

>diff --git a/layout/xul/base/src/nsXULPopupManager.cpp b/layout/xul/base/src/nsXULPopupManager.cpp
>--- a/layout/xul/base/src/nsXULPopupManager.cpp
>+++ b/layout/xul/base/src/nsXULPopupManager.cpp
>@@ -602,16 +602,27 @@ nsXULPopupManager::ShowTooltipAtScreen(n
>                                        PRInt32 aXPos, PRInt32 aYPos)
> {
>   nsMenuPopupFrame* popupFrame = GetPopupFrameForContent(aPopup, PR_TRUE);
>   if (!popupFrame || !MayShowPopup(popupFrame))
>     return;
> 
>   InitTriggerEvent(nsnull, nsnull, nsnull);
> 
>+  mCachedMousePoint = nsIntPoint(aXPos, aYPos);
>+  // coordinates are relative to the root widget
>+  nsPresContext* rootPresContext =
>+    popupFrame->PresContext()->GetRootPresContext();
>+  if (rootPresContext) {
>+    nsCOMPtr<nsIWidget> widget;
>+    rootPresContext->PresShell()->GetViewManager()->
>+      GetRootWidget(getter_AddRefs(widget));
>+    mCachedMousePoint -= widget->WidgetToScreenOffset();
>+  }
>+
>   popupFrame->InitializePopupAtScreen(aTriggerContent, aXPos, aYPos, PR_FALSE);
> 
>   FirePopupShowingEvent(aPopup, PR_FALSE, PR_FALSE);
> }
> 
> void
> nsXULPopupManager::ShowPopupWithAnchorAlign(nsIContent* aPopup,
>                                             nsIContent* aAnchorContent,
Attachment #475234 - Flags: review?(enndeakin) → review+
Comment on attachment 475234 [details] [diff] [review]
Without extraneous hunk

Yes, it's a regression fix for a regression fix. Sorry about that.
Attachment #475234 - Flags: approval2.0?
Comment on attachment 475234 [details] [diff] [review]
Without extraneous hunk

It's a blocker!
Attachment #475234 - Flags: approval2.0?
Whiteboard: [needs landing]
Duplicate of this bug: 599409
Duplicate of this bug: 601258
Blocks: abp
Pushed changeset b5744e9dd0f0 to mozilla-central.
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Whiteboard: [needs landing]
You need to log in before you can comment on or make changes to this bug.