Closed
Bug 367184
Opened 18 years ago
Closed 17 years ago
Event dialog does not resize [error in nsIDOMWindow.sizeToContent]
Categories
(Calendar :: Sunbird Only, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: foppe.benedictus, Unassigned)
References
Details
User-Agent: Mozilla/5.0 (X11; U; Linux i686; nl; rv:1.8.1) Gecko/20061010 Firefox/2.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a2pre) Gecko/20070116 Calendar/0.6a1
Edit event dialog does not resize when using more and less buttons.
Reproducible: Always
Steps to Reproduce:
1. Edit a event
2. Click More >>
after closing the dialog, it opens, when editing the event again in the 'more-mode' (sometimes, not always automaticly) Then:
1. Edit event
2. Click << Less
Actual Results:
http://supportbase.nl/Test/MoreLess1.png (after clicking more)
http://supportbase.nl/Test/MoreLess2.png (after clicking less)
http://supportbase.nl/Test/MoreLess3.png (after went to XChat, reporting this bug)
Results for Clicking less step by step
http://supportbase.nl/Test/Less1.png (opened edit dialog correct)
http://supportbase.nl/Test/Less2.png (clicked << Less)
http://supportbase.nl/Test/Less3.png (clicked cancel
After that the dialog closes on the upper cancel or close.
Expected Results:
Resize the dialog to a dialog in which I can see all options and resize the dialog back to its original size.
When trying to click the more, cancel or ok button after having clicked less, I expected it to close or expand again and not showing the working buttons.
Build: 2007011603
I work with Ubuntu 6.10
The error console gave 2 errors:
Error: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMWindow.sizeToContent]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://calendar/content/calendar-event-dialog.js :: toggleDetails :: line 917" data: no]
Source File: chrome://calendar/content/calendar-event-dialog.js
Line: 917
and
Error: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMWindow.sizeToContent]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://calendar/content/calendar-event-dialog.js :: toggleDetails :: line 908" data: no]
Source File: chrome://calendar/content/calendar-event-dialog.js
Line: 908
Confirmed on Mac OS X 10.4.8 with build: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a2pre) Gecko/20070116 Calendar/0.6a1
One note: When I edited the event for the second time, it appeared in the minimized view. I hit ESC to disappear the window and on the second edit, the oddities started to occur.
Also, this seems to work fine on the branch.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 2•18 years ago
|
||
I was not able to reproduce the error using Windows trunk build of Sunbird.
I can confirm as regression using Linux trunk build of Sunbird:
Works in Calendar/0.4a1 (2006-12-07-03-trunk)
Fails in Calendar/0.4a1 (2006-12-08-03-trunk)
Checkins to directory mozilla/: http://tinyurl.com/2jaxop
Keywords: regression
Summary: Edit event dialog does not resize → Event dialog does not resize [error in nsIDOMWindow.sizeToContent]
Version: unspecified → Trunk
Comment 4•18 years ago
|
||
just want to add that even after you resize, all of the details (description, attendees, url, status, etc) are incorrectly empty (though the information is preserved if you hit cancel and try to edit again).
Comment 5•18 years ago
|
||
I spent some time debugging this too. The error is being returned here
http://lxr.mozilla.org/mozilla/source/layout/base/nsDocumentViewer.cpp#3093
because the call to ResizeReflow didn't do anything, and the height that gets returned is the same as was passed in: NS_UNCONSTRAINEDSIZE.
If you apply this patch
diff -u -r1.515 nsDocumentViewer.cpp
--- nsDocumentViewer.cpp 23 Feb 2007 04:50:06 -0000 1.515
+++ nsDocumentViewer.cpp 3 Mar 2007 00:45:20 -0000
@@ -3067,6 +3067,7 @@
nsIFrame *root = presShell->GetRootFrame();
NS_ENSURE_TRUE(root, NS_ERROR_FAILURE);
+ root->AddStateBits(NS_FRAME_HAS_DIRTY_CHILDREN);
nscoord prefWidth;
{
it forces ResizeReflow() to process all the frames, and the error goes away and everything else works. But this is obviously not fixing the root cause of the problem. For whatever reason, toggling the collapsed attributes on the grid rows is not causing their DIRTY bits to bubble up to the parent frame.
I tried to reproduce this bug in a standalone .xul file, but was unsuccessful. My standalone dialog always opened at the full size of the dialog. So it never shrank down, and it never triggered any errors.
By the way, the reason that the details fields are incorrect is because when SizeToContent() fails it causes an exception which aborts the toggleDetails() function before it ever calls loadDetails(). That also means that the gDetailsShown flag doesn't get maintained correctly. Changing the order of things in calendar-event-dialog.js so that the SizeToContent() call happens last will avoid some of that mess. That way even though it fails, you can still manually resize the dialog and everything else will work. e.g.:
Index: calendar-event-dialog.js
===================================================================
RCS file: /cvsroot/mozilla/calendar/base/content/calendar-event-dialog.js,v
retrieving revision 1.62
diff -u -r1.62 calendar-event-dialog.js
--- calendar-event-dialog.js 27 Feb 2007 11:16:30 -0000 1.62
+++ calendar-event-dialog.js 3 Mar 2007 00:53:31 -0000
@@ -949,20 +949,14 @@
elem.collapsed = false;
}
detailsButton.setAttribute("label", lessLabel);
- this.sizeToContent();
-
- if (gDetailsShown) {
- // Focus the description
- document.getElementById("item-description").focus();
- // We've already loaded this stuff before, so we're done
- return;
+ if (!gDetailsShown) {
+ loadDetails();
}
- loadDetails();
-
// Now focus the description
document.getElementById("item-description").focus();
+ this.sizeToContent();
}
function loadDetails() {
Comment 6•18 years ago
|
||
Tested the windows XULRunner trunks I can confirm the regression range:
seems to be between 2006-12-07 and 2006-12-08
Comment 7•18 years ago
|
||
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-12-07+00%3A00%3A00&maxdate=2006-12-08+09%3A00%3A00&cvsroot=%2Fcvsroot is a bonsai query for the approximate range of checkins there. Note that included in that range is the landing of the reflow branch.
Comment 8•18 years ago
|
||
bug 371508 seems to be caused by the same issue
Comment 9•18 years ago
|
||
My current workaround used in a XUL project:
try {
// adjust the window
window.sizeToContent();
}
catch(e) {
setTimeout("window.resizeTo(window.outerWidth,document.documentElement.boxObject.height+30)",10);
}
Updated•18 years ago
|
Blocks: reflow-refactor
Comment 10•17 years ago
|
||
can we close this issue? since we moved to new event/task UI this seems to be not valid any more
Whiteboard: [qa discussion needed]
Comment 11•17 years ago
|
||
Fixed by checkin for bug 296893.
Status: NEW → RESOLVED
Closed: 17 years ago
Keywords: regression
Resolution: --- → FIXED
Whiteboard: [qa discussion needed]
Comment 12•17 years ago
|
||
Could you make sure there's a bug filed on the underlying Gecko bug? If the reflow branch broke something, we should fix it, whether or not it still affects Sunbird.
Comment 13•17 years ago
|
||
(In reply to comment #12)
> Could you make sure there's a bug filed on the underlying Gecko bug?
According to Comment #8 this might be Bug 371508
You need to log in
before you can comment on or make changes to this bug.
Description
•