58701 - timer events aren't being handled in embedding case.

Status: VERIFIED FIXED

(Core Graveyard :: Embedding: APIs, defect, P3)

Description

[Judson Valeski]

we're not pumping timer events in embedding. subsequently HTTP meta refresh
isn't working.

Comment 1

[Doug Turner (:dougt)]

This also happens on gtk.  if you try the embedding binary located:

ftp.mozilla.org/pub/mozilla/nightly/2000-11-01-06-Mtrunk/

and try a site which tries a meta refresh, nothing will happen.  However, if you
run gtkEmbed from the dist directory, refreshes do happen.  I think that this is
because the nsappshell is present in this case.

Comment 2

[rpotts (gone)]

Attachment: Patch to WinEmbed.cpp

Comment 3

[rpotts (gone)]

I've just attached a little patch which causes WinEmbed to process low prioroty 
timer events in its message Q.

This is *not* a fix for the real problem...  Just a band-aid which allows 
browser buster to work in WinEmbed.

-- rick

Comment 4

[rpotts (gone)]

According to LXR the nsITimerQueue interface is *only* used by Windows (and 
OS2).  So timers must be processed differently on Linux and Mac :-(

-- rick

Comment 5

[Doug Turner (:dougt)]

As for the linux dist which is produce part of the daily build, the problem is
that I was missing the timer so.  This was once built as a static lib, but now
it is shared.  This should be fix in monday's build.  

Comment 6

[Judson Valeski]

a=valeski on adding the timer.so to the embed manifest.

Comment 7

[Judson Valeski]

-> pavlov

Comment 8

[Judson Valeski]

*** Bug 51093 has been marked as a duplicate of this bug. ***

Comment 9

[Chris Waterson]

This is why winEmbed hangs. Apply attached patch to fix & collect data...

Comment 10

[Judson Valeski]

This is arguably a blocker.

The problem is that timer events aren't being processed the same way as
"regular" events. IMO, timer events should be the same.

Comment 11

[Stuart Parmenter]

er, so why is this assigned to me?  the problem on linux was that it was missing 
the .so.  Timer events should be getting processed as part of the gtk main loop 
so as long as that is running, there shouldn't be any problem.  I have no idea 
how timers are handled on other platforms.

Comment 12

[Paul Wyskoczka]

Updating QA Contact

Comment 13

[Chris Waterson]

Attachment: updated patch after adam's re-write

Comment 14

[Chris Waterson]

With the above patch, winEmbed seems to get a bit further, but is also 
occasionally hanging while loading pages. I'll break into the debugger next time 
that happens and try to figure out what's going on.

Comment 15

[Judson Valeski]

r=valeski on the 01/10/01 19:33 patch.

Comment 16

[Chris Waterson]

Hey jud, if I understand correctly, `that patch ain't right'. (See rpotts 
comment on 2000-11-01.) Jud, I'm giving this bug back to you because it seems 
to be a win32-specific issue, and pavlov isn't going to fix it.

Comment 17

[Judson Valeski]

understood, but it does start pumping the events for winEmbed (workaround - 
which I'll checkin).

Comment 18

[Chris Waterson]

jud: you mentioned that this got broken when somebody else `fixed' event 
handling...could we get that person on the cc list for this bug? (Or at least 
xref with the bug whose fix broke this bug...)

Comment 19

[Judson Valeski]

Lowe, you out there?

Comment 20

[Chris Waterson]

cc'ing adam, who just added an NS_HandleEmbeddingEvent() call

Comment 21

[Adam Lock]

Yes, winEmbed now calls NS_DoIdleEmbeddingStuff when its message queue is empty 
so it should process timer events.

Give me a URL to try it out on and I'll tell you if it solves this problem or 
not. Note that I've only added these methods to Win32 - other platforms are 
still waiting for their implementation.

Comment 22

[Chris Waterson]

adam: I was seeing a problem with HTTP <META> refresh. If you can get behind the
firewall, you'll see it at http://btek/cgi-bin/buster.cgi -- the first few URLs
will load, and then it will `stall'.

Comment 23

[Adam Lock]

winEmbed now appears to work fine with this URL, loading the pages without 
stalling. I think the problem is solved so marking this fixed. Reopen if you 
think it isn't.

Comment 24

[Adam Lock]

Reopening this bug for the time being and reassigning to me. 

I have a patch for the 100% CPU issue in the latest winEmbed and I want to be 
sure it still fixes stalled timers.

Comment 25

[Adam Lock]

Reassign

Comment 26

[Adam Lock]

Fix for 100% CPU usage has gone in. Marking fixed again

Comment 27

[Michael Dunn]

Correction: Changing QA contact for the Embed API bugs to David Epstein.

Comment 28

[Chris Waterson]

David, try using this URL to verify

  <http://www.maubi.net/cgi-bin/buster.cgi>

Comment 29

[David Epstein]

Thanks Chris. I tried this "Browser Buster II" url out in the debuggable
20010820 build. Since winEmbed hasn't been supported in awhile (was getting a
lot of asserts), I used mfcEmbed. cc'ing Chak to find out if mfcEmbed is fully
supporting timer events. NS_DoIdleEmbeddingStuff() is used in mfcEmbed, but
didn't see NS_HandleEmbeddingEvent().

This url cycles through about 10-15 web sites, visiting each site for 20-30
seconds. The last url is at American Airlines. In mfcEmbed, only got one assert
at www.onlinecreditnow.com (it's happening in nsFocusController.cpp, which I
think there's an open bug for).

In the 6.1 mozilla trunk build 20010830, it stopped on the onlinecreditnow.com
window. After closing it, it finished with American Airlines. Is this supposed
to be the last url of this script?! It displays "500.list" in the top display
area, so I thought maybe there are 500 urls to load.

So it appears that the timer events are working except for this one glitch where
it stopped loading. I won't verify this unless we're OK with these results.

Comment 30

[David Epstein]

verifying. the "glitch" above is probably a windowing issue and isn't related to
timing.