Status bar updates fail after using NPN_GetURL
Reed Bement
another developer: http://forums-test.mozillazine.org/viewtopic.php?f=27&t=757625
Using the Gecko API:
Using NPN_Status or JavaScript to updated the status bar works fine
until a call to NPN_GetURL(mNpp, "http://192.168.1.126/~reedb/
render.php", NULL); is made.
After the post has completed, and called successfully
NPP_DestroyStream, the status bar displays "Transferring data from
x...".
All calls to update the status bar text now fail (NPN_Status is a void
function unfortunately). The only thing that will clear the message is
reloading the page.
Possibilities:
1.The browser is stuck in STATE_TRANSFERRING and repeatedly updating
the status bar.
2. NPP_Status is now failing on one of the checks in
nsGlobalWindow::SetStatus
3. Something else not being destroyed
I debugged a bit into NPN_Status, enough to see that I would need to
setup symbols and source for the browser to go much further. Does
anybody else have any ideas or failing that a pointer to debugging
tips/tutorial for the recent FireFox browsers?
TIA, -Reed
Martin Husemann
> All calls to update the status bar text now fail (NPN_Status is a void
> function unfortunately). The only thing that will clear the message is
> reloading the page.
>
managed to debug this further yet.
Martin
Reed Bement
I'll add one more point of interest: all of the calls to NPN_Status
take place on thread 000 in my case (the same thread which created the
Plugin object). So it looks like this is a separate issue from the
following:
I hope to have more time to debug this further tomorrow, but still
would welcome any advice.
TIA, -Reed
Reed Bement
> On Dec 21, 1:11 am, Martin Husemann <mar...@aprisoft.de> wrote:
>
> > Reed Bement schrieb:> All calls to update the status bar text now fail (NPN_Status is a void
> > > function unfortunately). The only thing that will clear the message is
> > > reloading the page.
>
> > Just a "me too" - I'm seeing the same with a plugin I wrote but haven't
> > managed to debug this further yet.
>
> > Martin
>
> I'll add one more point of interest: all of the calls to NPN_Status
> take place on thread 000 in my case (the same thread which created the
> Plugin object). So it looks like this is a separate issue from the
> following:
>
>
> I hope to have more time to debug this further tomorrow, but still
> would welcome any advice.
>
> TIA, -Reed
So this is a dup of Bugzilla@Mozilla – Bug 383811. From looking about
in the bug database it looks like quite a few people have hit this but
no one is currently working on it. You can switch to another tab and
back and the last status that was written by NPN_Status will be
displayed. This means that we can eliminate item #2 above as a
possibility (2. NPP_Status is now failing...). Can any of the dev's on
the list tell me how the status message is painted, and I'll work back
from there. I have working symbols and a 100% repro case. All I need
is a pointer to the correct source (on http://mxr.mozilla.org/) and I
can continue my investigation.
TIA, -Reed
Reed Bement
> can continue my investigation.
>
> TIA, -Reed
Update subject.
Boris Zbarsky
> Can any of the dev's on the list tell me how the status message is painted
"Painfully".
In general, I'd think that NPN_Status should land you in
nsPluginInstanceOwner::ShowStatus which calls
nsContentTreeOwner::SetStatus(WithContext), which calls the setJSStatus
function in browser.js which calls updateStatusField, which either uses
the thing passed to setJSStatus or not, depending; if it decides to use
it it sets the label property on a XUL label which changes some text
nodes in the XUL DOM, etc, etc. The painting happens after the XUL
reflows and so forth.
-Boris