41206 - Text inserted into composer is initially invisible

Status: VERIFIED FIXED

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

Description

[John Morrison]

Overview Description:
  Text inserted into composer is initially invisible

Steps to Reproduce:
1) start browser, then launch composer
2) choose Debug->Insert Text from the menu, or use middle-mouse 
   to paste in something from the clipboard

Actual Results:
  Nothing visible in the document (except for a few random pixels)

Expected Results:
  The text.

3) Now select what should be visible, and it becomes fully visible

Reproducibility: always

Build Date & Platform Bug Found:
 2000060108 linux

Additional Builds and Platforms Tested On:
 smoketesting now -- mac and win32 to be checked

Comment 1

[rubydoo123]

setting to dogfood and nsbeta2, assigning to mike to take a look at this, this 
may be a repercussion from 41088

Comment 2

[Andreas Franke (gone)]

On PC/Linux, build 2000053120, there is a similar problem with the URL field:
1) Position the curser in the URL field after the last character
2) Use backspace key to delete the URL displayed
3) Paste a URL from the clipboard with middle-mouse-button.
Result: The curser moves to the right, but the pasted URL is not visible.
However, if you press return, the page loads without problems.

Comment 3

[Akkana Peck]

I'm not seeing this on a 2000060108 release build.  When I paste, the text
appears right away, but the caret disappears (which might also be Mike's issue
since he checked in some caret visibility code yesterday).  Clicking brings it
back.  Debug|InsertText shows the text right away, and the caret stays visible.

Comment 4

[leger]

Putting on [nsbeta2-][dogfood+] radar.  Does not need a fix ASAP for daily work, 
but we should fix this for beta2.

Comment 5

[Brian Ryner (not reading)]

I'm not seeing this either, on my debug build.

Comment 6

[Akkana Peck]

Using mozilla all day, I've seen this once.  It's very disconcerting when it
happens (though scrolling made it appear) but I haven't found a way to reproduce
it reliably.

Comment 7

[R.K.Aa.]

Linux 2000-060108
Tried to paste a small 5k textfile into composer. This hung the browser and
composer for 10 minutes with 96% CPU usage before i killed it. Reproducable.

Comment 8

[mjudge]

i tried this today on 3 different machine/configs. seems ok to me. the pasting 
5K of data hanging machine should be a different bug. i will make another bug 
and file it to kin.  i thiiink that it is kin that handles big pastes..

Comment 9

[John Morrison]

I see this every time I start composer, since I first noticed it last Thursday.
I also see it in a debug build, pulled ~5pm today. Come on down ...

Comment 10

[rubydoo123]

ok, I sat with John and I now see what is happening. Dragged Akkana over and 
showed her too. Akkana and I talke to Pav to see if he had any ideas. Pav said 
he would be willing to look at this. The text is there, it's just that it 
doesn't render if focus is not preset or something like that.

Comment 11

[rubydoo123]

I believe the 41371 is a dup of this bug and will mark it as such, if it isn't 
please reopen it.

Comment 12

[rubydoo123]

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

Comment 13

[lchiang]

Sujay - when this is fixed, please let me know and I'll try the mail case
specified in the dup bug.  Thanks.

Comment 14

[Stuart Parmenter]

I've taken a look at this and don't understand what is happening.  I can't
reproduce it every time.  When it doesn't happen, the first time you click in
the window or paste or something it repaints the entire window about 5 times. 
In the case where it doesn't work, it only paints a section twice and a much
smaller area than the entire window.

Comment 15

[rubydoo123]

bummer -- I was hoping you would find something. John, can you try this in 
tomorrows builds? Mike is turning ender lite on and that may fix this problem.

Comment 16

[Peter Trudelle]

I saw pav reproduce this, but only once in about a dozen tries, and even then 
it only happens immediately after creating the window, and only part of the 
text is invisible.  Is this really stopping anyone from using the product, or 
could we downgrade to nsbeta2+?
cc'ing pavlov because he's spent some time on it, and saari because beppe 
mentioned that it seemed to be focus-related. 

Comment 17

[rubydoo123]

I will downgrade the status, and prefer to put this out to M17. Now that I 
understand that it is on first focus and not if Composer has been open and been 
in 'edit' mode for a period of time. This is really, at this point, more of a 
polish issue. 

Leaving nsbeta2 keyword

Comment 18

[lchiang]

Our duplicate bug indicates this problem occurs in mail compose window's subject
and body as well.  Can you see it you see it more often in the mail compose window?

Comment 19

[John Morrison]

I will check composer in tomorrow's builds. (I note, though, that for my 
'vanilla' rh6.1 system, in either a debug or release build, this happens 
everytime I paste into a new document, and it is all of the pasted text 
that is invisible).

Comment 20

[kinmoz]

I see this bug everytime I paste into a TextField. Pav, were you just trying to
reproduce this in Composer?

Comment 21

[rubydoo123]

Kin is able to reproduce this in textfields in the browser, consistently. I'm 
bumping this one back up to where it was -- dogfood+, nsbeta2- and assigning to 
Kin

Comment 22

[kinmoz]

Accepting bug.

Comment 23

[John Morrison]

I believe this is fixed, post ender-lite. For the 100% reproducible (on my 
machine :-]) testcase that started this bug report, with 2000060908 linux 
release build, I can no longer reproduce this behaviour. I would mark this 
fixed, but this has been a 'now you see it, now you don't bug' so ... does
anyone else still see this behaviour?

Comment 24

[kinmoz]

There is still a bug in the way the ViewManager and Linux implementation of
nsWindow interact with eachother. I've verified that when the bug happens, the
wrong clip rect is being used.

The bug goes away in TextFields when Ender-Lite is enabled because the
underlying window hierarchy changes.

This bug should still exist for composer, though I haven't been able to
reproduce it yet in composer. I'll try reproducing it in the PlainText mail
compose window.

Comment 25

[kinmoz]

Ok so it looks like I can reproduce this problem pretty easily in the editor's
plain text window (Debug->PlainText), and in PlainText MailCompose.

I'm removing the "most likely FIXED" comment from the Status Whiteboard.

Comment 26

[kinmoz]

So the problem seems to be that nsPresShell::SetCaretEnabled() was modified to 
call FlushPendingNotifications() (nsPresShell.cpp revision 3.296).

This sometimes causes a reflow to happen while we are trying to paint which is a 
very bad idea!

On linux the nsWindow::Update() method paints the region specified by 
mUpdateArea. If a reflow should happen while we are painting, portions of the 
current window may be invalidated. These new invalidations will be dropped on 
the floor after we are done painting and return to nsWindow::Update() because it 
clears mUpdateArea.

I commented out the FlushPendingNotifications() call in SetCaretEnabled(), and I 
can't seem to reproduce the caret cruft problems ,on Linux and Win32, it was 
originally supposed to fix.

Comment 27

[kinmoz]

Attachment: nsPresShell.cpp patch that fixes the problem.

Comment 28

[Simon Fraser [no longer active]]

That patch looks good. Alas, it does not fix drawing problems on Mac (bug 42289)

Comment 29

[kinmoz]

Fix checked in:

    mozilla/layout/html/base/src/nsPresShell.cpp  revision 3.310

r=[e-mail], a=[e-mail] 

Comment 30

[sujay]

looks fine to me....John can you verify this also on your end? thanks!

Comment 31

[John Morrison]

This had ceased to happen on my system June 11th, and today's linux verif.
build works fine (shows the pasted text on pasting). Thanks kin/sujay.