368501 - Table Properties Windows Cut Off

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[Carsten Book [:Tomcat]]

Attachment: Cut off Table Properties Window

Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1.2pre) Gecko/20070125 Thunderbird/2.0b2pre Mnenhy/0.7.4.10002 ID:2007012804


1. Create a new Message
2. Insert a Table
3. Double Click in the table to reach the table properties
4. The Window is cut off

Under Solaris Thunderbird 2 Beta 2 i can change the size of this window, under the Windows Build its not possible to change the Size of the Table Properties Window.

Comment 1

[Merlyel]

Under Windows (XP SP2) bug can be fixed by:
<Thunderbird program folder>\chrome\comm.jar\content\editor\EdTableProps.js
add string to Startup() function:
string 289:  SetWindowLocation();
so it's now: 
string 289:  SetWindowLocation();
string 290: window.sizeToContent();
Though under Linux (Slackware 10.1) it does not help.

PS. Got same trouble with:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.9) Gecko/20061207 Thunderbird/1.5.0.9 ID: 2006120700
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.2pre) Gecko/20070116 Thunderbird/2.0b2 ID:2007011615
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070128 Thunderbird/3.0a1 ID:2007012803

Comment 2

[Carsten Book [:Tomcat]]

changing because comment #1

Comment 3

[Merlyel]

Add:
Changed screen resolution in Linux to 1600x1200 and Table Properties window was not cut off anymore.
Changed back to 1024x768 - the window is cut off again.

Linux Version: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.2pre) Gecko/20070116 Thunderbird/2.0b2 ID:2007011615

Comment 4

[[:Aleksej]]

Happens on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.2pre) Gecko/20070111 SeaMonkey/1.1 -- not cut off while loading, becomes cut off when loaded completely.

WFM on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a2pre) Gecko/20070128 SeaMonkey/1.5a

Comment 5

[[e-mail]]

As Merlyel pointed out in #maildev on IRC, the table properties window fills some of its menulists in its onload handler. However, they don't reflow until after the window has loaded, so that the intrinsic size is miscomputed.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Don't we run sizeToContent() _after_ the onload handler?  Or is the problem that the events from bug 348304 are still outstanding?

If so, it sounds like what we need is a way for a flush of some sort to process said events...

Comment 7

[Boris Zbarsky [:bzbarsky]]

And this sounds like a core XUL bug to me.

Comment 8

[Neil Deakin]

Attachment: This testcase shows the issue

The menulist isn't being sized properly, as it has no child menupopup, and SizeToPopup returns early before firing the event. Adding an empty child <menupopup> inside the menulist in this testcase makes the sizing work properly.

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 256677 [details]
This testcase shows the issue

this is actually different bug, I think, because this happens also on 2.0.0.0

Comment 10

[Olli Pettay [:smaug][[e-mail]]]

Attachment: possible patch, make async a bit less async

Instead of using nsIRunnable it is better to take advantage of the 
existing nsIReflowCallback object posting.
nsIReflowCallbacks will be handled right after reflow.
Tested the regressions bug 348304 caused, and couldn't see any
problems, nor did I see any crashes using the crash testcases.
When using nsIReflowCallback, nsASyncMenuGeneration may not need to
block onload, but I left it there just to reduce the possibility for
new regressions. ((Un)BlockOnload could be removed from trunk
later.)

Comment 11

[Olli Pettay [:smaug][[e-mail]]]

Attachment: for 1.8

Comment 12

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 257152 [details] [diff] [review]
possible patch, make async a bit less async

>Index: layout/xul/base/src/nsMenuFrame.cpp
>+  nsCOMPtr<nsIReflowCallback> cb = new nsASyncMenuInitialization(this);
>+  GetPresContext()->PresShell()->PostReflowCallback(cb);

This needs to handle out-of-memory.  Same for the other two callsites.

I'd like roc or dbaron to also look this over... but in general it seems ok.

r=bzbarsky with the OOM issue addressed.  Thanks for fixing this!

Comment 13

[Olli Pettay [:smaug][[e-mail]]]

Attachment: with OOM checks

Comment 14

[Olli Pettay [:smaug][[e-mail]]]

Attachment: for 1.8

Comment 15

[Robert O'Callahan (:roc) (email my personal email if necessary)]

You're not setting aFlushFlag, but you should.

I'm about to check in a patch that makes nsIReflowCallback a non-COM interface.

Comment 16

[Olli Pettay [:smaug][[e-mail]]]

Attachment: for trunk, using deComified reflowcallback

Roc, I decided to use the |delete this| you suggested. A bit ugly
but should work.
Otherwise I should have added virtual destructor to nsIReflowCallback
and add PresShell-owns logic to Post/HandleReflowCallback etc.

Comment 17

[Olli Pettay [:smaug][[e-mail]]]

Attachment: For 1.8, setting aFlushFlag

This should be now ok for branch.

Comment 18

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 257345 [details] [diff] [review]
for trunk, using deComified reflowcallback

OK. You should add to the comment for PostReflowCallback in nsIPresShell.h that we guarantee that these callbacks will be called, even if reflow fails. And can you please check that's true? :-)

Comment 21

[Daniel Veditz [:dveditz]]

Do we need a separate 1.8.0-branch patch?

Comment 22

[Olli Pettay [:smaug][[e-mail]]]

1.8 patch works with 1.8.0 branch too

Comment 23

[Daniel Veditz [:dveditz]]

Comment on attachment 257347 [details] [diff] [review]
For 1.8, setting aFlushFlag

approved for 1.8.0.12 and 1.8.1.4, a=dveditz for drivers

Comment 25

[Carsten Book [:Tomcat]]

verified fixed 1.8.1.4 using my steps to reproduce from this bug with Build
Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1.4pre) Gecko/20070427 Thunderbird/2.0.0.4pre Mnenhy/0.7.5.0 ID:2007043003

and verified fixed 1.8.0.12 using Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.0.12pre) Gecko/20070430 Thunderbird/1.5.0.12pre ID:2007043008

Table Properties are looking good now and the window is not cut off. Adding verified keyword.

Comment 26

[Jerome Borsboom]

The 1.8 patch for this bug seems to cause bug 383120. I don't know enough of firefox's internals to understand how it can cause this bug, but removing it from current cvs, solves the issue. Can someone knowledgeable look over this?