Closed Bug 324312 Opened 14 years ago Closed 12 years ago
Item dialog widens with every click on More/Less button or Alarm dropdown or Event/Task dropdown
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.
OS: Windows 2000 → All
Hardware: PC → All
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.
Attachment #209364 - Flags: first-review?(jminta)
Comment on attachment 209364 [details] [diff] [review] make item dialog resizable :-) Curious how it's resizable by default on Linux. r=jminta
Attachment #209364 - Flags: first-review?(jminta) → first-review+
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.
Attachment #209546 - Flags: first-review?(mvl)
(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.
Summary: Item dialog widens with every click on More/Less button → Item dialog widens with every click on More/Less button or Alarm dropdown
*** 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 email@example.com Bugspam filter: TorontoMostafaMove
Assignee: mostafah → nobody
*** 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)
Attachment #209546 - Flags: first-review?(mvl) → first-review-
Maybe we can port the patches from bug 310900
Whiteboard: [patch in hand]
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.
Attachment #231491 - Flags: first-review?(daniel.boelzle) → first-review?(michael.buettner)
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
Assignee: jminta → nobody
Status: ASSIGNED → NEW
Flags: blocking0.3+ → blocking0.3-
Target Milestone: --- → Sunbird 0.3
*** Bug 350847 has been marked as a duplicate of this bug. ***
Not going to make the 0.3 train.
Target Milestone: Sunbird 0.3 → Sunbird 0.4
*** Bug 356455 has been marked as a duplicate of this bug. ***
Component: Sunbird Only → General
QA Contact: sunbird → general
This is a cosmetic issue and won't block 0.5.
Flags: blocking-calendar0.5? → blocking-calendar0.5-
Not going to make the 0.5 train.
Target Milestone: Sunbird 0.5 → ---
Summary: Item dialog widens with every click on More/Less button or Alarm dropdown → Item dialog widens with every click on More/Less button or Alarm dropdown or Event/Task dropdown
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
Whiteboard: [swag: 1d] → [qa discussion needed]
Fixed by checkin for bug 296893.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [qa discussion needed]
Version: Trunk → unspecified
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).
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
This is only happening in the old event dialog. Since 0.7 we've moved to a new dialog. --> WONTFIX
Status: REOPENED → RESOLVED
Closed: 13 years ago → 12 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.