Ccing Rick Potts as the fix for this bug will probably come out of the work he is doing to separate the nsILinkHandler API into two interfaces: one for link event reporting and the other for link style setting. Rick, do you think I should assign this bug to you?
I should clarify things. I just checked in the last of the code to make the status bar update when you mouse over links. As it turns out, I do get notifications of a sort when the mouse leaves a link. The status is set to a blank string when that happens. I reported a new bug 7784 because the status bar text won't draw an empty string. I've remedied that, short term, by adding some code to navigator.js to reset to the previous "Document: Done" status text when it gets set to an empty string. The point about the JS reflection of status and defaultStatus still applies; we need to figure out how to handle that in general. I think nsWebShell should not convert the link mouse-over to a SetStatus call, however. It's just wrong for nsWebShell to decide how mousing over a link should be communicated to the user. It should notify somebody (probably a settable "nsILinkHandler") that this has happened, and let the application (window) decide how to deal with it.
Adding radha to the cc list. This bug should get fixed as part of her work in making embedders of webshells implement the nsILinkHandler interface. This interface has the OnOverLink method to send notifications about mouse overs. Radha, should I re-assign this bug to you?
Ooops, my bad. This should be on my plate. I guess I should add a OnLinkLeave method to nsILinkHandler to propagate "mouse leaving link" information to you. I'll look into doing that for M9.
Summary: Notifications not sent when mouse leaves links → [Webshell] Notifications not sent when mouse leaves links
I've got to dive into block/inline code while Kipp is away. I'm not gonna be able to do this for M9. CCing Scott to see if he wants to attack this as he transitions into becoming webshell owner.
Scott, as per our talk yesterday, assigning this to you so that you can start getting your feet wet with webshell stuff.
as instructed: changing all bugs that do not block M9 to M10
this is not a blocker. It is a reasonable request for a slight redesign of the webshell api. linking to bug 13374.
(Mass-) Re-assigning [Webshell] bugs to travis, on the advice of dp, et al. Many of these may be invalid in the new world of the re-written webshell, but he certainly needs to be aware of these issues. Hope this helps you, travis.
Move to M16 for now ...
Target Milestone: M15 → M16
I've cleaned up all this code, it all works now. Status messages you will notice are properly shown even when leaving a link.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.