14413 - Cannot listen for NS_PAINT events for nsMacWindow from my event handler

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect, P3)

Description

[mark.lin]

I have some methods which create and initialize a top level window widget
(really nsMacWindow). When it gets created, I pass in a event handler function
as an argument.

In this function where I receive nsGUIEvents for my top level nsMacWindow,
I do not get any NS_PAINT events.

I took a look at nsMacWindow.cpp and in the method OnPaint(), I tried returning
PR_TRUE instead of PR_FALSE, and then I get NS_PAINT events. I think this is
because in the UpdateWidget() method of nsWindow, it does:

if (OnPaint(paintEvent))
    DispatchWindowEvent(paintEvent);

Since nsMacWindow::OnPaint() always returns PR_FALSE, DispatchWindowEvent()
never gets called. Is there another way of getting paint events that I'm not
aware of?

This is for OJI on the Mac. I need to listen for NS_PAINT events because I need
to register top level windows which gets created by the plugin and I tell the
plugin to repaint itself whenever appropriate.

Comment 1

[mark.lin]

Assigning as P1, because it is blocking bug #6872.

Comment 2

[Peter Trudelle]

The priority and target milestone fields are owned by the assigned engineer, the
bug reporter is not allowed to change them. Resetting to default.

Also, why did you mark this as blocker severity?

Comment 3

[mark.lin]

I marked this as blocker serverity because it is blocking me from fixing bug
#6872. I cannot get my bug cleared until this bug is fixed. That in my mind, is
the definition of a "blocker

Comment 4

[Peter Trudelle]

No, the definition of a blocker is "Blocks development and/or testing
work", and is intended only for when you are dead in the water, and cannot
proceed in the work you need to be doing.  What you are describing sounds more
like a simple dependency, which is already accounted for in this bug. If 6872
was a blocker but, then this one could be marked blocker too, but as it is, this
should be marked normal, like 6872.

Comment 5

[Peter Trudelle]

We're not familiar enough with this area to handle this bug.  Saari thinks beard
is the right person, reassigning

Comment 6

[Patrick C. Beard]

We should create a new kind of widget for hosting plugins, in my opinion. This
widget could intercept NS_PAINT events.

Comment 7

[Patrick C. Beard]

Paints get swallowed by frames, or perhaps even earlier, by the view manager. I
think we should probably have a special widget for hosting plugins.

Comment 8

[Patrick C. Beard]

Perhaps this should be owned by plugins.

Comment 9

[av (gone)]

Pierre, could you please have a quick look?

Comment 10

[Pierre Saslawsky]

Four months ago, the day after this bug was opened, dcone (for other reasons, I 
presume) changed nsMacWindow::OnPaint() to always return PR_TRUE.

Now if paint events get swallowed, it's by the frames or the view manager as 
described by beard on 2000-01-07 16:49. However I don't whether this affects the 
case of a plugin, which was the original problem.

[e-mail]: is it still a problem for you?

Comment 11

[drapeau]

Adding Loki to the CC list on this bug; Loki, when you get a chance, would you
please check to see if this bug is still hitting us or not?

Comment 12

[loki der quaeler]

moving to my weltschmerz email address off my modgock@eng

Comment 13

[Pierre Saslawsky]

This bug has been here for too long without action from the reporter. We don't 
have any sample code attached to it. Our own plugins work. The code looks fine. 
Marking fixed. Please don't hesitate to reopen if you feel that it was closed in 
error.

Comment 14

[loki der quaeler]

the reporter has quit, so is unlikely to file any further diagnostic information 
on this bug; as this was the blocker on 6872, i'm hazy to accept that this can be 
closed.. will investigate more.