24497 - 1st click to input field blinks its background

Status: VERIFIED DUPLICATE of bug 25947

(Core :: Layout: Form Controls, defect, P3)

Description

[Marko Macek]

The first time I click in input field (one line), the background is redrawn
(black or system default color) and then the widget is properly drawn. This
happens when at top of the page.

If the page is scrolled, the same thing happens, but doesnt take page scroll
position into account (drawing below the input field).

100% reproducible under Linux and Windows on 01-18,01-19 builds

Comment 1

[Peter Trudelle]

That's not an XPToolkit widget.  Changing component to HTML Form Controls,
reassigning, cc beppe in case it is an Editor problem.

Comment 2

[karnaze (gone)]

Reassigning to Rod.

Comment 3

[rods (gone)]

I am not sure there is much you can do about this steve, but here it is.

Comment 4

[Marko Macek]

I am not sure if it is a widget problem. But it does occur also for URL bar, not
just content widgets.

It seems to me like a 'first-refresh' problem with repainting or double
buffering (a guess).

Comment 5

[rubydoo123]

moving this out to m16

Comment 6

[Marko Macek]

When I open-in-new-window, the browser area also gets repainted: first in
default system color (while loading), then in black (short blink), then the page
background color is shown. So this seems like a repaint bug.

Comment 7

[rods (gone)]

For those who are wondering, the reason this occurs. This for single line text 
field we install the "editor" on the first click (focus) and this means a 
webshell is created and we actually are changing the display. That is why it 
flickers.

Comment 8

[rods (gone)]

This diff fixes it on windows:

Index: nsGfxTextControlFrame.cpp
===================================================================
RCS file: /cvsroot/mozilla/layout/html/forms/src/nsGfxTextControlFrame.cpp,v
retrieving revision 3.122
diff -r3.122 nsGfxTextControlFrame.cpp
1556c1556,1560
<   webShellWin->SetVisibility(PR_TRUE);
---
>   PRInt32 type;
>   GetType(&type);
>   if ((PR_FALSE==IsSingleLineTextControl()) || (NS_FORM_INPUT_PASSWORD == 
type)) {
>     webShellWin->SetVisibility(PR_TRUE);
>   }
2190a2195
>         webShellWin->SetVisibility(PR_TRUE);

It still flashes on Mac & Linux, I think because it is waiting for a paint 
message.

Comment 9

[Marko Macek]

The blinking also occurs when opening a new window. The patch will not fix it.
Should I file a new bug?

Comment 10

[buster]

as a reminder to Rod, we discussed using the view manager's batching methods to 
shut down painting during the webshell creation process.  that might fix this 
problem on other platforms.

Comment 11

[buster]

To [e-mail]:
The paint problems on opening a new browser window are totally unrelated to this 
bug.  Please do submit a separate bug report.  And thanks for your help!

Comment 12

[buster]

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

Comment 13

[Marko Macek]

Recently the background color drawn during blink has changed. But the blinking

is still visible when the browser view is not at top-left.

Comment 14

[buster]

this is primarily a performance issue, duping to my placeholder bug for text 
control perf.

*** This bug has been marked as a duplicate of 25947 ***

Comment 15

[Sebastian Späth]

VERIFY dupe