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

Status: RESOLVED FIXED

(Firefox :: Bookmarks & History, defect)

Description

[Régis Caspar]

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

Comment 1

[Myk Melez [:myk] [@mykmelez]]

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.

Comment 2

[Régis Caspar]

(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. 

Comment 3

[Ria Klaassen (not reading all bugmail)]

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.

Comment 4

[Ria Klaassen (not reading all bugmail)]

Oh well, also on trunk.

Comment 5

[Ria Klaassen (not reading all bugmail)]

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.

Comment 6

[Myk Melez [:myk] [@mykmelez]]

(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.

Comment 7

[Myk Melez [:myk] [@mykmelez]]

Attachment: patch v1: turns off busy state after load

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).

Comment 8

[Ria Klaassen (not reading all bugmail)]

I don't see this anymore in trunk.

Comment 9

[Brett Wilson]

This patch says "places". It is only a places bug? If so, it should not be marked blocking Fx2.

Comment 10

[Myk Melez [:myk] [@mykmelez]]

Fix checked in to trunk and 1.8 branch.  Also, moving to the Bookmarks component, since this is not Places-specific.