18801 - [superwin] bugzilla query page looks terrible

Status: VERIFIED FIXED

(Core :: Layout, defect, P3)

Description

[Christopher Blizzard (:blizzard)]

The superwin query page looks terrible in the superwin branch.  For some reason,
it creates grey empty blocks all over the place.  The main code has a similar
effect although it's not as bad.

Comment 1

[Christopher Blizzard (:blizzard)]

Actually, this happens on any page where there is a textarea.

Comment 2

[Christopher Blizzard (:blizzard)]

I now know that the gray window in question is mClipView created in
nsScrollingView::CreateScrollControls

Comment 3

[Christopher Blizzard (:blizzard)]

Ok, I've narrowed this down to being triggered by an html problem so I'm
starting to think it's a layout problem of some kind.  I'm going to make two
attachments of html, one that I don't have any problems with and one that I do.
The only difference between the two is that the one that triggers the problem
has a <CENTER> tag in it.

Comment 4

[Christopher Blizzard (:blizzard)]

Attachment: html that triggers bug

Comment 5

[Christopher Blizzard (:blizzard)]

Attachment: html that doesn't have bug

Comment 6

[Christopher Blizzard (:blizzard)]

Ok, I set a break point at nsGfxTextControlFrame::CreateWebShell and found out
something interesting.  For this page will create one control frame:

http://people.redhat.com/blizzard/testing/not_broken_easy.html

and this one will create two:

http://people.redhat.com/blizzard/testing/broken_easy.html

The only difference between these two is that one has a center tag in it.
Here's the bug that I've had open on this:

http://bugzilla.mozilla.org/show_bug.cgi?id=18801

I've also checked and here are the statistics on these pages:

not_broken_easy.html

2 nsScrollingView
1 GfxTextControlFrame

broken_easy.html

3 nsScrollingView
2 GfxTextControlFrame

Comment 7

[Christopher Blizzard (:blizzard)]

Here's some more debugging output.  Looks like the widgets associated with the
views, or the views themselves are never released.

nsGfxTextControlFrame constructor
TextControlFrame 0x8338120 just created webshell 0x8338180
nsWindow::nsWindow for 0x833a5b0
just loaded new widget 0x833a5b0 for view 0x833a548
initializing webshell 0x8338180 from widget in view 0x833a548
nsWindow::nsWindow for 0x833ab60
nsWindow::nsWindow for 0x8353908
just loaded new widget 0x8353908 for view 0x8357b98
nsWindow::nsWindow for 0x8363808
just loaded new widget 0x8363808 for view 0x83637a0
nsWindow::nsWindow for 0x8363c80
just loaded new widget 0x8363c80 for view 0x8363c08
just loaded new widget 0x8364158 for view 0x8364060
just loaded new widget 0x83646f0 for view 0x83645f8
nsGfxTextControlFrame destructor
about to destroy webshell 0x8338180 win in frame 0x8338120
about to set mWebShell 0x8338180 to null in frame 0x8338120

Comment 8

[Christopher Blizzard (:blizzard)]

Ok, more clues.  The window is the clip view in nsScrollingView.  Apparently,
this window is supposed to be destroyed by something other than the
nsScrollingView destructor since it's just set to null.

Comment 9

[Christopher Blizzard (:blizzard)]

Fix checked in.  The problem was in the Destroy() code in the native widget
code.  That's why it wasn't showing up on Windows or Mac.

Comment 10

[Chris Petersen]

With the Nov 29th Linux build (1999112908), this problem has been fixed.

Comment 11

[Christopher Blizzard (:blizzard)]

Please ignore the spam.  Changing address.

Comment 12

[Christopher Blizzard (:blizzard)]

bustage from my reassign

Comment 13

[Christopher Blizzard (:blizzard)]

bustage from my reassign