Closed
Bug 368501
Opened 18 years ago
Closed 18 years ago
Table Properties Windows Cut Off
Categories
(Core :: XUL, defect)
Core
XUL
Tracking
()
RESOLVED
FIXED
People
(Reporter: cbook, Assigned: smaug)
References
Details
(Keywords: regression, verified1.8.0.12, verified1.8.1.4, Whiteboard: wait for more trunk baking -- test menus)
Attachments
(3 files, 5 obsolete files)
37.51 KB,
image/jpeg
|
Details | |
7.83 KB,
patch
|
roc
:
review+
roc
:
superreview+
|
Details | Diff | Splinter Review |
11.39 KB,
patch
|
roc
:
review+
roc
:
superreview+
dveditz
:
approval1.8.1.4+
dveditz
:
approval1.8.0.12+
|
Details | Diff | Splinter Review |
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.
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
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•18 years ago
|
||
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•18 years ago
|
||
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•18 years ago
|
||
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...
Blocks: 348304
Flags: blocking-thunderbird2?
![]() |
||
Comment 7•18 years ago
|
||
And this sounds like a core XUL bug to me.
Assignee: mscott → nobody
Component: Message Compose Window → XP Toolkit/Widgets: XUL
Flags: blocking-thunderbird2?
Product: Thunderbird → Core
QA Contact: message-compose → xptoolkit.xul
![]() |
||
Updated•18 years ago
|
Severity: minor → normal
Component: XP Toolkit/Widgets: XUL → XP Toolkit/Widgets: Menus
Flags: in-testsuite?
Flags: blocking1.9?
Flags: blocking1.8.1.3?
Keywords: regression
QA Contact: xptoolkit.xul → xptoolkit.menus
![]() |
||
Updated•18 years ago
|
Flags: blocking1.8.0.11?
Comment 8•18 years ago
|
||
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.
Updated•18 years ago
|
Attachment #256677 -
Attachment is patch: false
Updated•18 years ago
|
Attachment #256677 -
Attachment mime type: text/plain → application/vnd.mozilla.xul+xml
Assignee | ||
Comment 9•18 years ago
|
||
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
Assignee | ||
Updated•18 years ago
|
Attachment #256677 -
Attachment is obsolete: true
Assignee | ||
Comment 10•18 years ago
|
||
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.)
Attachment #257152 -
Flags: review?(bzbarsky)
Assignee | ||
Comment 11•18 years ago
|
||
Assignee | ||
Updated•18 years ago
|
Attachment #257162 -
Attachment is patch: true
Attachment #257162 -
Attachment mime type: text/x-patch → text/plain
![]() |
||
Comment 12•18 years ago
|
||
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!
Attachment #257152 -
Flags: review?(bzbarsky) → review+
Assignee | ||
Updated•18 years ago
|
Attachment #257152 -
Flags: superreview?(roc)
Assignee | ||
Comment 13•18 years ago
|
||
Assignee: nobody → Olli.Pettay
Attachment #257152 -
Attachment is obsolete: true
Attachment #257162 -
Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #257269 -
Flags: superreview?(roc)
Attachment #257152 -
Flags: superreview?(roc)
Assignee | ||
Comment 14•18 years ago
|
||
You're not setting aFlushFlag, but you should.
I'm about to check in a patch that makes nsIReflowCallback a non-COM interface.
Assignee | ||
Comment 16•18 years ago
|
||
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.
Attachment #257345 -
Flags: superreview?(roc)
Assignee | ||
Updated•18 years ago
|
Attachment #257269 -
Flags: superreview?(roc)
Assignee | ||
Updated•18 years ago
|
Attachment #257269 -
Attachment is obsolete: true
Assignee | ||
Comment 17•18 years ago
|
||
This should be now ok for branch.
Attachment #257270 -
Attachment is obsolete: true
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? :-)
Attachment #257345 -
Flags: superreview?(roc)
Attachment #257345 -
Flags: superreview+
Attachment #257345 -
Flags: review+
Attachment #257347 -
Flags: superreview+
Attachment #257347 -
Flags: review+
Assignee | ||
Updated•18 years ago
|
Attachment #257347 -
Flags: approval1.8.1.4?
Assignee | ||
Updated•18 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Comment 21•18 years ago
|
||
Do we need a separate 1.8.0-branch patch?
Flags: blocking1.8.1.4?
Flags: blocking1.8.1.4+
Flags: blocking1.8.0.12?
Flags: blocking1.8.0.12+
Assignee | ||
Comment 22•18 years ago
|
||
1.8 patch works with 1.8.0 branch too
Assignee | ||
Updated•18 years ago
|
Attachment #257347 -
Flags: approval1.8.0.12?
Updated•18 years ago
|
Whiteboard: wait for more trunk baking -- test menus
Comment 23•18 years ago
|
||
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
Attachment #257347 -
Flags: approval1.8.1.4?
Attachment #257347 -
Flags: approval1.8.1.4+
Attachment #257347 -
Flags: approval1.8.0.12?
Attachment #257347 -
Flags: approval1.8.0.12+
Assignee | ||
Updated•18 years ago
|
Flags: blocking1.9?
Keywords: fixed1.8.0.12,
fixed1.8.1.4
Reporter | ||
Comment 25•18 years ago
|
||
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•18 years ago
|
||
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?
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: xptoolkit.menus → xptoolkit.widgets
You need to log in
before you can comment on or make changes to this bug.
Description
•