11262 - [PP] default page not appearing until click

Status: VERIFIED FIXED

(Core :: DOM: Editor, defect, P3)

Description

[Kathleen :Brade]

problem on Mac (not on Windows; Unix unknown)
in AppRunner, choose Editor from the Tools menu
notice that when the window comes up that the editing area is white
click in that space
notice that the default page appears

Comment 1

[buster]

sujay:  could verify this bug still exists on mac with today's build?  If so,
does it occur on Linux?  It does not occur on Windows.  Simon, Joe, have you
heard anything about Mac that would be causing this?

Comment 2

[Kathleen :Brade]

yes, I see the problem with this morning's tree on Mac.  Simon confirmed that he sees it also.µ

Comment 3

[buster]

joe, could you look into this mac bug? if it is trivial, please try to get it in
for M9.  otherwise it can wait for next milestone.

Comment 4

[Simon Fraser [no longer active]]

This is almost certainly not an editor bug; it's going to be somewhere in layout,
or perhaps Mac GFX.

Comment 5

[Mike Pinkerton (not reading bugmail)]

this is now affecting browser, and the content below the main toolbar doesn't
paint until a repaint is forced or you resize the window. clicking in the blank
content area doesn't help.

Do we have any ideas? Is this still mac only? What's the status?

Comment 6

[Mike Pinkerton (not reading bugmail)]

adding myself to cc list

Comment 7

[Joe Francis]

i cannot get to this bug right now.  i strongly suspect it has nothing to do with
editor stuff.  if someone else wants to grab it, go for it.  setting to m10 in
case no one volunteers...

Comment 8

[Kathleen :Brade]

add dcone to cc list since he may have some ideas.

Comment 9

[Simon Fraser [no longer active]]

Lemme see if I can figure this out for M9.

Comment 10

[Simon Fraser [no longer active]]

This problem appears to be related to setting focus and handling activate events.
If the window comes up in the foreground, and handles an activate event,
then certain calls to SetFocus() are made, and the window content fails to
draw. If the window comes up in the background (e.g. when debugging), then no
activate event is handled, adn the window shows up fine.

Comment 11

[Simon Fraser [no longer active]]

So it turns out that this is caused by an editor hack, which tries to redraw the
content when we get focus (to redraw the selection and caret). The editor code
calls
 viewmgr->UpdateView(view,nsnull,NS_VMREFRESH_IMMEDIATE);
but for some reason this isn't causing the correct drawing to happen.

Comment 12

[Simon Fraser [no longer active]]

I have a fix for this, which I think fixes an error in the Mac widget code.

nsWindow::Update() updates the dirty region of a window, and then calls
ValidRect() to validate the bounds of the widget (i.e. "window") that just
drew.

The problem is that updating the dirty region of the window only draws pixels in
the *exposed* parts of this widget (which might be none), and yet the call to
ValidRect() tells the OS that none of the pixels within the bounds of this widget
need to be redrawn.

I believe that the correct fix is to change the call to ValidRect(& macRect)
to ValidRgn(mWindowRegion). Will someone who knows more about the Mac widget
code please comment.

Comment 13

[Simon Fraser [no longer active]]

saari, or pierre, could you take a look at this please?

Comment 14

[Kathleen :Brade]

I tried Simon's recommended fix and notice that it does fix this bug.  However, I
see a problem (with the fix) that bringing up the image dialog (partially
obscuring the editor) doesn't update the toolbars when the dialog is dismissed (I
clicked cancel).

I think I like the new bug I've encountered better than the old since it's an
extra step away for users to find this one.  %-/

Comment 15

[Simon Fraser [no longer active]]

OK, so that fix messes up toolbar drawing in general, so it's not right.

Comment 16

[Simon Fraser [no longer active]]

This is going to have to wait until pierre gets back. M10

Comment 17

[Pierre Saslawsky]

It works now, most certainly thanks to the fix that beard did in Invalidate().

Comment 18

[sujay]

looks fixed now...verified in 9/2 build.