[Webshell] Notifications not sent when mouse leaves links

VERIFIED FIXED in M16

Status

()

P3
normal
VERIFIED FIXED
20 years ago
17 years ago

People

(Reporter: law, Assigned: travis)

Tracking

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

20 years ago
I'm hooking into the notifications that go to the nsIBrowserWindow when the user
mouses over a link.  This works.

But, when the mouse leaves a link, I need some notification (so I can reset the
status area).  I think this is a hole in the current nsIWebShell notification
scheme.

In looking at the JavaScript documentation, I see that there is also the notion
of "defaultStatus."  Perhaps there should be new methods in nsIBrowserWindow:
  SetDefaultStatus
  GetDefaultStatus
and the default for onmouseout should be "window.status =
window.defaultStatus;".

Comment 1

20 years ago
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?
(Reporter)

Comment 2

20 years ago
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.

Comment 3

20 years ago
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?

Updated

20 years ago
Status: NEW → ASSIGNED
OS: OS/2 → All
Target Milestone: M9

Comment 4

20 years ago
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.

Updated

20 years ago
Summary: Notifications not sent when mouse leaves links → [Webshell] Notifications not sent when mouse leaves links

Comment 5

20 years ago
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.

Updated

20 years ago
Assignee: nisheeth → scc
Status: ASSIGNED → NEW

Comment 6

20 years ago
Scott, as per our talk yesterday, assigning this to you so that you can start
getting your feet wet with webshell stuff.

Updated

20 years ago
Status: NEW → ASSIGNED

Comment 7

20 years ago
as instructed: changing all bugs that do not block M9 to M10

Updated

20 years ago
Blocks: 13374
Target Milestone: M10 → M15

Comment 8

20 years ago
this is not a blocker.  It is a reasonable request for a slight redesign of the
webshell api.  linking to bug 13374.

Updated

19 years ago
Blocks: 15160

Comment 9

19 years ago
(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.
(Assignee)

Updated

19 years ago
No longer blocks: 13374
Status: NEW → ASSIGNED
(Assignee)

Updated

19 years ago
Depends on: 13374

Comment 10

19 years ago
Move to M16 for now ...
Target Milestone: M15 → M16
(Assignee)

Comment 11

19 years ago
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

Comment 12

19 years ago
marking VERIFIED
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.