Closed Bug 337038 Opened 16 years ago Closed 16 years ago

After bookmark properties dialog closure, mouse pointer is stuck in "busy" state when hovering chrome

Categories

(Firefox :: Bookmarks & History, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Firefox 2 beta1

People

(Reporter: regis.caspar+bz, Assigned: myk)

References

Details

(Keywords: fixed1.8.1)

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060507 Minefield/3.0a1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060507 Minefield/3.0a1

If you right click a bookmark entry, select properties and click cancel, mouse cursor when hovering Firefox chrome (eg. menus or toolbars) is set to "busy". 

Loading some url makes it go back to normal. 

(Happens even in -safe-mode) 

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060507 Minefield/3.0a1 ID:2006050704 [cairo]

Reproducible: Always

Steps to Reproduce:
1. Right-click a bookmark entry
2. Select properties
3. Click cancel
4. Move your mouse over the menubar or over a toolbar

Actual Results:  
Cursor is a "busy" one (http://img297.imageshack.us/img297/7540/screenshot0012ul.png)

Expected Results:  
normal cursor
I suspect this is because the microsummary service uses a hidden iframe in the main window to load the page (to check for microsummaries specified by the page), and some progress listener for the tabbrowser widget sees that load, turns on the busy cursor, and then never turns it off instead of ignoring the load entirely.

Does it happen when you open the bookmark properties dialog for a bookmark currently loaded into a browser tab?  If the culprit is the microsummary service, then it shouldn't happen if the page is already loaded, since the service will just query that already-loaded document object.
Assignee: nobody → myk
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #1)
> Does it happen when you open the bookmark properties dialog for a bookmark
> currently loaded into a browser tab?  If the culprit is the microsummary
> service, then it shouldn't happen if the page is already loaded, since the
> service will just query that already-loaded document object.
No it doesn't happen. 

When I rightclick on a bookmarklet in my bookmarks toolbar and choose properties, it executes the bookmarklet partially (shows a dialog because there is no selection in the page), then when I close the dialog it shows the properties window. Then it also shows the "busy" cursor mentioned here.
Does not happen with all bookmarkets, only the ones that get a selection in the page. They show also the dialog when there *is* a selection in the page.
No errors in the JSConsole.

Tested on branch, WinXP.
Oh well, also on trunk.
Flags: blocking-firefox2?
Don't know if this is related to this bug, but since I have one microsummary amongst my bookmarks (non-functional in trunk, WinXP) I see sometimes a "busy" cursor when I hover over the tabs or over the toolbars. I don't know when or why this happens. When I load another page the behaviour stops.
The behaviour also stops when I delete the microsummary but I'm not quite sure; it can be coincidence.
(In reply to comment #5)
> Don't know if this is related to this bug, but since I have one microsummary
> amongst my bookmarks (non-functional in trunk, WinXP) I see sometimes a "busy"
> cursor when I hover over the tabs or over the toolbars. I don't know when or
> why this happens. When I load another page the behaviour stops.
> The behaviour also stops when I delete the microsummary but I'm not quite sure;
> it can be coincidence.

It's a manifestation of the same bug, which is caused by way the microsummary service loads page content when generating or updating microsummaries.  I'm on the case.
Status: NEW → ASSIGNED
Flags: blocking-firefox2? → blocking-firefox2+
Target Milestone: --- → Firefox 2 beta1
Whiteboard: [swag: 1d]
This patch unsticks the cursor, so that it changes back to its regular state after loading the page content for a microsummarized page.  That fixes this bug, although it's still not optimum behavior.

Ideally we shouldn't allow the cursor to ever get into the busy state when the microsummary service loads page content in the background, but that's another bug (bug 340035).
Attachment #224146 - Flags: review?(mconnor)
I don't see this anymore in trunk.
Attachment #224146 - Flags: review?(mconnor) → review+
Attachment #224146 - Flags: approval-branch-1.8.1?(mconnor)
Attachment #224146 - Flags: approval-branch-1.8.1?(mconnor) → approval-branch-1.8.1+
This patch says "places". It is only a places bug? If so, it should not be marked blocking Fx2.
Fix checked in to trunk and 1.8 branch.  Also, moving to the Bookmarks component, since this is not Places-specific.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Component: Places → Bookmarks
Resolution: --- → FIXED
QA Contact: places → bookmarks
Keywords: fixed1.8.1
Whiteboard: [swag: 1d]
You need to log in before you can comment on or make changes to this bug.