Closed Bug 466009 Opened 11 years ago Closed 11 years ago

Calendar property page is missing Cancel/Ok

Categories

(Calendar :: General, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: dbo, Assigned: Fallen)

Details

Attachments

(1 file, 1 obsolete file)

Seems the dialog is too small.
Flags: blocking-calendar1.0+
Works for me using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081120 Calendar/1.0pre (BuildID: 20081120121029).
I had a similar problem (bug 453686 - "Calendar Properties dialog is cropped on right side" with Lightning 0.9pre).  I'm not sure if anyone ever discovered the cause of the bug.  Unfortunately I don't have time to deal with Shredder yet so I can't test it with the current nightly.
Attached patch resizable dialogs (obsolete) — Splinter Review
Seems that (in my case) the properties dialog had a small persistent size that I couldn't fix. I think it makes sense to have resizable dialogs here, e.g. in case of long email identities. IMO the same applies for the calendar creation wizard.
Assignee: nobody → daniel.boelzle
Status: NEW → ASSIGNED
Attachment #350319 - Flags: review?(philipp)
Comment on attachment 350319 [details] [diff] [review]
resizable dialogs

Are you sure this is the right solution? In light of backing out bug 394195, I think making the dialog resizable is not the right solution...
Philipp could you elaborate why you don't think the dialog should be resizable? Email identities could be quite long, and sizeToContent() doesn't seem to cover them thoroughly. I agree the size shouldn't be persistent, but since it's been persistent for quite some time, we either need to use a new id or leave it persistent to not bug users that need to resize their dialog, like me ;-)
Attached patch Fix - v2Splinter Review
Id prefer a patch like this: Dont persist any dimension attributes, but make the dialog resizable. This way the dialog doesnt have strange sizes if the beginner user accidentally resizes the window and then closes it.

We may also want to set the minimum dimensions on load, i.e from the boxObject just after sizeToContent() has been called. This way the user will not accidentally make the window smaller than it should be. Ill leave this up to you.
Attachment #350319 - Attachment is obsolete: true
Attachment #354675 - Flags: review?(daniel.boelzle)
Attachment #350319 - Flags: review?(philipp)
Attachment #354675 - Flags: review?(daniel.boelzle) → review+
Comment on attachment 354675 [details] [diff] [review]
Fix - v2

I leave minimal sizes for coming bugs; think this patch is sufficient.

r=dbo
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/967068fc2d02>

-> FIXED
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
OS: Mac OS X → All
Hardware: x86 → All
Resolution: --- → FIXED
Target Milestone: --- → 1.0
Assignee: daniel.boelzle → philipp
These bugs are likely targeted at Lightning 1.0b1, not Lightning 1.0. If this change was done in error, please adjust the target milestone to its correct value. To filter on this bugspam, you can use "lightning-10-target-move".
Target Milestone: 1.0 → 1.0b1
You need to log in before you can comment on or make changes to this bug.