Item dialog widens with every click on More/Less button Windows: Every time you click the [More>>] or [<<Less] button on the new item dialog the width increases by some pixels. The width remains after restarting Sunbird. It is not possible to resize the dialog. (The same happens on Linux but there you can resize the dialog.) So after editing several events the dialog is not usable anymore because parts of the dialog are off-screen.

confirmed Linux/x86; my build from today's CVS, 20060123.

This patch gives the user the ability to resize the dialog also on windows. It does not solve the problem about the width increasing on every click.

Comment on attachment 209364 [details] [diff] [review] make item dialog resizable :-) Curious how it's resizable by default on Linux. r=jminta

Comment on attachment 209364 [details] [diff] [review] make item dialog resizable patch checked in

OK, an in depth explanation because this bug is cited in the comment code... 'Location' (in the Less view) is longer than 'Description' (in the More view), so that means that when we hit 'More >>', the first column expands. If this first column doesn't have flex set on it, it will push the whole dialog wider. If it does have flex on it, then that increases the distance between the labels and the input-fields they correspond to. By making the flex of the second column ridiculously large, we force this not to happen, because the labels barely get to expand (1%), and the input fields expand a lot (99%), filling in the empty space. The advantage is that this solution ought to be compatible with all localizations.

(In reply to comment #5) > OK, an in depth explanation because this bug is cited in the comment code... > 'Location' (in the Less view) is longer than 'Description' (in the More view), > so that means that when we hit 'More >>', the first column expands. Out of curiosity: This explains why the dialog widens when I click on More>>. When I click <<Less I see that the second column (containing the edit fields) shifts back to the left. So the first column (containing the labels) resizes properly I think. Nevertheless the dialog widens again.

i guess we are bitten by bug 230959 and/or bug 310900 and/or bug 90276

*** Bug 329946 has been marked as a duplicate of this bug. ***

There's a new dialog on the way, see https://bugzilla.mozilla.org/show_bug.cgi?id=324657. It's probably not worth while to address this issue, since the new dialog won't have a details-button.

*** Bug 335156 has been marked as a duplicate of this bug. ***

Reassigning all automatically assigned bugs from Mostafa to nobody@m.o Bugspam filter: TorontoMostafaMove

*** Bug 345334 has been marked as a duplicate of this bug. ***

Comment on attachment 209546 [details] [diff] [review] hack fix It seems that the problem is not in the flex, but in the persist. I removed the persist line completely, and it all works correctly. The flex stuff is not needed. (It would be weird to explain a 1 pixel difference based on a 10 pixel difference in label length)

Maybe we can port the patches from bug 310900

This is a port of the fix mvl mentioned in the previous comment. seems to fix things for me here on the mac.

Comment on attachment 231491 [details] [diff] [review] different hack fix Seems that I am not the appropriate reviewer for this patch.

The proposed patch does not fix the problem. First of all, I didn't understand why the 1 pixel difference should be responsible for the dialog constantly expanding? Could you please shed some light on this? Second, in my tests the window.innerWidth and 'calendar-event-dialog'.boxObject.width were always equal. Your explanation in comment #5 seems to nail down the root cause of the problem. I would propose to dynamically walk the list of labels in the first column, finding the maximum width those labels need. After that, add a dynamic stylesheet rule that forces the first column to have the previously calculated width. I'm not really sure whether or not this suggestion really solves the problem. But if so, it seems to be the appropriate fix to the problem.

I've made my proposals here, someone else can pick this up and fight their way through the 'right fix' for a bug that's not in our code. -> nobody

*** Bug 350847 has been marked as a duplicate of this bug. ***

Not going to make the 0.3 train.

*** Bug 356455 has been marked as a duplicate of this bug. ***

This is a cosmetic issue and won't block 0.5.

Not going to make the 0.5 train.

this iss atest

fingers crossed for next release, i hate this.

Ditto. Minor, but a real annoyance.

can we close this issue? since we moved to new event/task UI this seems to be not valid any more

Fixed by checkin for bug 296893.

ehm, no, this is not fixed. at least not by that bug, because it is a very old one. It doesn't show in the latest version of the event dialog, that is still in a temporary promotion. Or did the deal change again?

This bug still exists in our standard dialog (i.e. the non-prototype one).

This is only happening in the old event dialog. Since 0.7 we've moved to a new dialog. --> WONTFIX