81917 - nsIWebBrowserChrome::setStatus() doesn't work as documented

Status: VERIFIED DUPLICATE of bug 99009

(SeaMonkey :: UI Design, defect, P3)

Description

[rbs]

From within layout, to display a message on the status bar onMouseOver, when I 
try to use:

  setStatus(nsIWebBrowserChrome::STATUS_SCRIPT, aStatusMessage)

it doesn't work. However, it works if I change the call to instead use the flag
'STATUS_LINK'.

The code under consideration is below:
http://lxr.mozilla.org/seamonkey/source/layout/mathml/base/src/nsMathMLmactionFr
ame.cpp#362

Am I missing something else that has to be done to display a message on a 
content that is not necessarily a link?

Comment 1

[Adam Lock]

I traced (by hand) the path through which this call goes and I don't see 
anything to prevent JS statis text from being handled correctly.

Chrome object you're calling is implemented here:

http://lxr.mozilla.org/seamonkey/source/xpfe/appshell/src/nsContentTreeOwner.cpp
#311

When called it handles STATUS_SCRIPT by calling SetJSStatus on 
an nsIXULBrowserWindow object associated with the window. This is a Javascript 
object implemented here:

http://lxr.mozilla.org/seamonkey/source/xpfe/browser/resources/content/nsBrowser
StatusHandler.js#85

As far as I can tell this should work as intended.

If you have a reproducable test case, I can try step debugging through to 
confirm or disprove this.

Comment 2

[rbs]

STEPS TO REPRODUCE:
1) With a MathML-enabled build, visit /layout/mathml/tests/various.xml
   (http://lxr.mozilla.org/seamonkey/source/layout/mathml/tests/various.xml)
   Follow the indication about mousing over on that page. 
   -> Observe that you see the status message (this is because I changed the
      code to use STATUS_LINK).

2) a) Edit the corresponding source file (nsMathMLmactionFrame.cpp) and change
      STATUS_LINK back to STATUS_SCRIPT.
   b) Re-compile /layout/ for the change to take effect.
   c) re-visit /layout/mathml/tests/various.xml
      -> the status messages don't show up anymore.

Comment 3

[Adam Lock]

I stepped through and it is going the route I thought it was so docshell is in
the clear. However, when it reaches setJSStatus in nsBrowserStatusHandler.js, it
fails at the final hurdle. After copying the text value to a jsStatus member, it
it calls updateStatusField(). Source for method is below:

http://lxr.mozilla.org/seamonkey/source/xpfe/browser/resources/content/nsBrowserStatusHandler.js#113

At the top of this method you will see a strange looking assignment that assigns
what text to display depending on values in various members in this order of
precedence:

overLink (link hovering)
status (general loading status text)
jsStatus
jsDefaultStatus
defaultStatus

As you can see, jsStatus is 3rd highest priority being general loading info
stored in "status". The "status" is set to "Read http://foo/various.xml" so the
"jsStatus" is never displayed.

The simple fix would be to put "status" below "jsStatus", but this might have
knock on effects.

Reassigning to XP Apps for consideration to whether swapping the order would be
okay.

Comment 4

[Adam Lock]

CC'ing Jag

Comment 5

[jag (Peter Annema)]

I think you can safely move jsStatus before status.

rbs, can you test that and see if it addresses your needs? Could you also see if
there's any negative impact on the status text during "normal" browsing
activities?

Comment 6

[Paul Chen]

nav triage team:

Marking mozilla1.0

Comment 7

[Paul Chen]

marking p3

Comment 8

[Paul Chen]

marking mozilla1.2

Comment 9

[rbs]

Noted that the fix for bug 99009 implemented the suggestion made here.

*** This bug has been marked as a duplicate of 99009 ***

Comment 10

[sairuh (rarely reading bugmail)]

v