Fields for custom alarm time cut off in dialog New event

RESOLVED FIXED

Status

RESOLVED FIXED
12 years ago
12 years ago

People

(Reporter: thorsten, Unassigned)

Tracking

Details

(Whiteboard: [no l10n impact])

Attachments

(5 attachments)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1b2) Gecko/20060821 Firefox/2.0b2
Build Identifier: Lightning 0.1+ (2006030606)

In the dialog New Event the three fields for a custom alarm time are cut off.

See attached screenshot.

Reproducible: Always

Steps to Reproduce:
1. Start TB and create a new Event in Lightning
2.
3.
(Reporter)

Comment 1

12 years ago
Created attachment 236828 [details]
Screenshot of the New Event dialog
(Reporter)

Comment 2

12 years ago
I think this bug should be solved for the 0.3 release.

Flags: blocking0.3-
(Reporter)

Updated

12 years ago
Flags: blocking0.3- → blocking0.3?

Comment 3

12 years ago
Duplicate of bug 351323?
Flags: blocking0.3? → blocking0.3-
(In reply to comment #2)
> I think this bug should be solved for the 0.3 release.

To nominate something as blocking the release, please set the flag to "?".
The release drivers will then determine whether it will block (+) or not (-) and set the flag appropriately.

For more information, see http://wiki.mozilla.org/Calendar/For_Everyone/Blocking_Flags



(In reply to comment #3)
> Duplicate of bug 351323?

It could be related, but the axis of the cutoff is different. Perhaps a dupe.
Summary: Fields fors custom alarm time cut off in dialog New event → Fields for custom alarm time cut off in dialog New event
Using Branch (Tb 1.5.0.x, Tb 2.0a1) or Trunk (Tb 3.0a1) build? 
What happens when you resize the dialog? Do you have a regression range?
Maybe this is related to Bug 351323.
Flags: blocking0.3- → blocking0.3?
Summary: Fields for custom alarm time cut off in dialog New event → Fields fors custom alarm time cut off in dialog New event
Summary: Fields fors custom alarm time cut off in dialog New event → Fields for custom alarm time cut off in dialog New event
(Reporter)

Comment 7

12 years ago
Created attachment 236829 [details]
Screenshot of resized New Event dialog

Even when I resize the dialog box, the three fields still remain cut off.

I am using Thunderbird 1.5.0.5 and the lightning build 0.1+ (2006090506)
I think this is not a duplicate of Bug 351323. On Windows 2000 I can't see the custom alarm fields at all. But the dropdown menus stated in Bug 351323 are displayed fine.

WORKS with Tbird/2.0a1   (20060905) + Ltn/0.1+ (2006090506-mozilla1.8)

FAILS with Tbird/1.5.0.5 (20060719) + Ltn/0.1+ (2006090506-mozilla1.8)
FAILS with Tbird/1.5.0.7 (20060905) + Ltn/0.1+ (2006090506-mozilla1.8)

Tbird/3.0a1 (20060905) + Ltn/0.1+ (2006090508-trunk) shows Bug 351323
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

12 years ago
Flags: blocking0.3? → blocking0.3+
The problem only occurs with Event dialog, with Task dialog everything is OK.

WORKS with Tbird/1.5.0.5 (20060719) + Ltn/0.1+ (2006-08-18-06-mozilla1.8)
FAILS with Tbird/1.5.0.5 (20060719) + Ltn/0.1+ (2006-08-19-14-mozilla1.8)

Bug 287550 was checked in during that time and changed the dialog. 
Maybe this revealed a xul bug regarding hidden/colapsed elements that is present on MOZILLA_1_8_0_BRANCH but fixed on MOZILLA_1_8_BRANCH.

I also need to test if the changes from Bug 350375 can help here.
Whiteboard: [no l10n impact]
Same problem on Linux. In addition I have to revert my statement from Comment #9: Task dialog is also affected: Selecting custom alarm shows the custom alarm fields - but the privacy field above is no longer visible.

Looking closer I think this is caused by the "max-height: 10em;" style set on calendar-attendee-list element.
OS: Windows XP → All
Created attachment 237389 [details]
Screenshot on Mac

Interestingly enough, this bug doesn't appear on Mac.
Created attachment 237402 [details]
Screenshot on Mac - Lightning 2006-09-08 on Tbird 1.5.0.5 (official, under Rosetta)
Created attachment 237486 [details] [diff] [review]
increase the max-height value

I verified that this is caused by the "max-height: 10em;" style set on
calendar-attendee-list element. 

Removing that style rule fixes the problem. But then the attendee list will grow to infinite height with each line added.

I tested adding/removing flex attribute/style rules in various places but none fixed both problems.

So I decided to increase the max-height value. Setting to 12em makes it work fine on Windows 2000 and Ubuntu Linux. This should also work on Windows XP because the fields are less cut off than on Windows 2000 according to the screenshot. On Mac OS X the problem doesn't show at all - probably this was developed on Mac and 10em is the right size for this system.

Note: This doesn't really fix the problem. It just makes it disappear for now. I suggest to use this change for 0.3 unless someone comes up with a better fix.
Attachment #237486 - Flags: second-review?(dmose)
Attachment #237486 - Flags: first-review?(mattwillis)
Comment on attachment 237486 [details] [diff] [review]
increase the max-height value

Still works on Mac okay.
Attachment #237486 - Flags: first-review?(mattwillis) → first-review+
Comment on attachment 237486 [details] [diff] [review]
increase the max-height value

dmose's queue is a bit full.
Attachment #237486 - Flags: second-review?(dmose) → second-review?(mvl)
Comment on attachment 237486 [details] [diff] [review]
increase the max-height value

This is totally the wrong way to fix this, but it seems that richlistbox is quite buggy. A simple testbox in a small window doesn't show a scrollbar...

So guess we have to live with this workaround for 
now. But please add a big XXX comment.

r=mvl
Attachment #237486 - Flags: second-review?(mvl) → second-review+
Patch with big ol' comment checked in on MOZILLA_1_8_BRANCH and trunk.

-> FIXED
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED

Comment 18

12 years ago
(In reply to comment #17)
> Patch with big ol' comment checked in on MOZILLA_1_8_BRANCH and trunk.
Works here. Windows XP. 
You need to log in before you can comment on or make changes to this bug.