Ben Hutchings wrote:
It seems like some parts of the Mozilla event handling machinery don't
like being recursed over, so in some cases events won't be processed
while an event handler (such as my on_net_state_change function) is
running.
Oh, right. The event queues try to prevent reentry... at
Ben Hutchings wrote:
DOM events shouldn't affect PLEvents
Do they not go through the same queue at some point?
DOM events always dispatch immediately; there is no queue involved.
-Boris
___
mozilla-embedding mailing list
mozilla-embedding@mozil
It seems like some parts of the Mozilla event handling machinery don't
like being recursed over, so in some cases events won't be processed
while an event handler (such as my on_net_state_change function) is
running.
I moved much of the state of on_net_state_change into a structure by a
class memb
Boris Zbarsky <[EMAIL PROTECTED]> wrote:
> Ben Hutchings wrote:
>> I assume you mean PL_ProcessPendingEvents?
>
> Yes.
>
>> That is not being called.
>
> Does it usually get called when you spin the GTK event loop?
Yes, it gets called 3 times during loading of my test page.
>> I wonder whether th
Ben Hutchings wrote:
I assume you mean PL_ProcessPendingEvents?
Yes.
That is not being called.
Does it usually get called when you spin the GTK event loop?
I wonder whether there's something wrong with the way I'm dispatching
the event, that can cause further events to be blocked?
DOM e
Boris Zbarsky <[EMAIL PROTECTED]> wrote:
> Ben Hutchings wrote:
>> As it is, the loop never exits. My actual code for
>> on_net_state_change includes some output statments which report its
>> arguments. They show that it is never called with the REQUEST and
>> STOP flags. If I remove the loop, i
I wrote:
> As it is, the loop never exits. My actual code for
> on_net_state_change includes some output statments which report its
> arguments. They show that it is never called with the REQUEST and
> STOP flags.
To be clear, I mean it is never called with the REQUEST and STOP flags
once this l
Ben Hutchings wrote:
As it is, the loop never exits. My actual code for
on_net_state_change includes some output statments which report its
arguments. They show that it is never called with the REQUEST and
STOP flags. If I remove the loop, it is called with these flags
during the next call to
Boris Zbarsky <[EMAIL PROTECTED]> wrote:
> Ben Hutchings wrote:
>> Surely I'd need to find the document first, and that's not possible
>> until it has at least started loading, which I would detect in the
>> same way.
>
> Fair enough. You can actually set the load handler on the window, but given
Ben Hutchings wrote:
Surely I'd need to find the document first, and that's not possible
until it has at least started loading, which I would detect in the
same way.
Fair enough. You can actually set the load handler on the window, but given
that you're doing things after onload that doesn't
Boris Zbarsky <[EMAIL PROTECTED]> wrote:
> Ben Hutchings wrote:
>> I'm using GtkMozEmbed and handling net_state_all signals (I think
>> those correspond to nsIWebProgressListener::OnStateChange) in order to
>> tell when pages have finished loading.
>
> This is on 1.7 branch, right?
Right.
> Is th
Ben Hutchings wrote:
I'm using GtkMozEmbed and handling net_state_all signals (I think
those correspond to nsIWebProgressListener::OnStateChange) in order to
tell when pages have finished loading.
This is on 1.7 branch, right? Is there a reason not to just use the page's
onload event here? O
Boris Zbarsky <[EMAIL PROTECTED]> wrote:
> Ben Hutchings wrote:
>> Then I guess the problem I'm having is that changes to images (which
>> are what I'm hoping to trigger) are asynchronous...
>
> Yes, changes to images are typically asynchronous. In fact, depending on
> what
> the change is, they
Ben Hutchings wrote:
Then I guess the problem I'm having is that changes to images (which
are what I'm hoping to trigger) are asynchronous...
Yes, changes to images are typically asynchronous. In fact, depending on what
the change is, they might have to hit the network, right?
-Boris
__
Boris Zbarsky <[EMAIL PROTECTED]> wrote:
> Ben Hutchings wrote:
>> I'm faking up mouse events and dispatching them through the DOM. So
>> far as I can tell, calling dispatchEvent on a node causes the event
>> handlers to run asynchronously
>
> dispatchEvent is synchronous.
Then I guess the proble
Ben Hutchings wrote:
I'm faking up mouse events and dispatching them through the DOM. So
far as I can tell, calling dispatchEvent on a node causes the event
handlers to run asynchronously
dispatchEvent is synchronous.
-Boris
___
mozilla-embedding ma
I'm faking up mouse events and dispatching them through the DOM. So
far as I can tell, calling dispatchEvent on a node causes the event
handlers to run asynchronously (presumably the event is queued for
running by the event loop?). How can I wait for an event to be
handled, or run the event loop
17 matches
Mail list logo
