Closed Bug 394195 Opened 17 years ago Closed 5 years ago

Dialogs need a scroll bar or minimum height/width

Categories

(Calendar :: Dialogs, defect)

defect
Not set
minor

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 1480338

People

(Reporter: ssitter, Assigned: Fallen)

References

Details

(Whiteboard: [no l10n impact])

Attachments

(4 files, 4 obsolete files)

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.7pre) Gecko/20070829 Calendar/0.7pre The prototype Event, Task, Recurrence, Custom Reminder, Attendee and Summary dialog doesn't persist the width and height set by user. Steps To Reproduce: 1. Start Sunbird with fresh profile 2. Open one of the dialogs mentioned above 3. Resize and close it 4. Reopen the dialog Actual Results: Width and height are set back to default value. Expected Results: Width and height is the same as in step 3.
Component: General → Theme
Product: Calendar → Firefox
Target Milestone: --- → Firefox 3
Oops, sorry, my bad, returning to the right component, awfully sorry about stomping your target milestone, please send hatemail to this address :(
Component: Theme → General
Product: Firefox → Calendar
Target Milestone: Firefox 3 → ---
Version: Trunk → Sunbird 0.7
Assignee: nobody → ssitter
Status: NEW → ASSIGNED
Attachment #343384 - Flags: review?(philipp)
Attachment #343384 - Flags: review?(philipp) → review+
Looks good, will take care of checkin tomorrow or tuesday. If someone wants to take over, please do so r=philipp
Keywords: checkin-needed
Summary: [Proto] Dialogs doesn't persist width and height set by user → Dialogs don't persist width and height set by user
Comment on attachment 343384 [details] [diff] [review] [checked in] persist width and height Checked in, changeset id 641:dbbd98fffbd3
Attachment #343384 - Attachment description: persist width and height → [checked in] persist width and height
Target Milestone: --- → 1.0
-> FIXED.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Attached image small edit dialog β€”
I discussed this issue with Christian and Philipp -> REOPENED, because without a scroll bar or a minimum height/width a very small edit dialog confuses the user.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee: ssitter → nobody
I think this is a serious UI issue, especially for new users. We should rethink this before 1.0
Flags: blocking-calendar1.0?
Flags: blocking-calendar1.0? → blocking-calendar1.0+
Status: REOPENED → NEW
Summary: Dialogs don't persist width and height set by user → Dialogs need a scroll bar or minimum height/width
Version: Sunbird 0.7 → Trunk
Assignee: nobody → daniel.boelzle
Attached patch Advanced backout - v1 (obsolete) β€” β€” Splinter Review
Stefan, this patch reverts the persist changes and also modifies the dialog ids. Do you have a different suggestion to fix this issue? If you want to persist the dialog sizes, it should be quite easy to do this in an extension. I think we should file/find a core bug that allows to make the minimum dialog size automatically be what sizeToContent() would do.
Assignee: daniel.boelzle → philipp
Status: NEW → ASSIGNED
Attachment #358611 - Flags: review?(ssitter)
Whiteboard: [needs review]
Comment on attachment 358611 [details] [diff] [review] Advanced backout - v1 I want to keep the current behavior. We shouldn't force the user to resize the dialog every time the dialog opens. If the user wants a smaller dialog he/she should be able to do this.
Attachment #358611 - Flags: review?(ssitter)
Stefan, do you have a suggestion how we can fix the open issues then: * Dialogs need a minimum height, but what height do we pick? * The event dialog and the task dialog have different minimum widths, right now they are cropped if you (on a clean profile) open the event dialog first and then the task dialog afterwards.
Whiteboard: [needs review] → [needs decision]
Whiteboard: [needs decision] → [needs decision][not needed beta]
Whiteboard: [needs decision][not needed beta] → [needs decision][not needed beta][no l10n impact]
Whiteboard: [needs decision][not needed beta][no l10n impact] → [not needed beta][no l10n impact][needs decision]
Attached patch Dynamic Solution - v2 (obsolete) β€” β€” Splinter Review
I tried a more dynamic solution that tries to set and remember the minimum dimensions per item type on the first opening of the event dialog. In subsequent openings the dialog would not resize unless it is smaller than the remembered minimum dimensions. The solution is quite fragile as I've seen it not work in all situations and it also causes flicker if the dialog is too small. Aside from that I wasn't able to really *enforce* the minimum dimensions. The user can still resize the dialog smaller even though min-width/min-height is set on the document element. Stefan, do you have any suggestions on how we can fix this? I don't think we should spend endless time on this, the best solution would be to allow setting some sort of css or attribute that automatically sets the min-dimensions to whatever sizeToContent() would do, somewhere down in toolkit.
(In reply to comment #12) > Aside from that I wasn't able > to really *enforce* the minimum dimensions. The user can still resize the > dialog smaller even though min-width/min-height is set on the document element. Enforcing minimum dimensions is bug 357725.
Whiteboard: [not needed beta][no l10n impact][needs decision] → [not needed beta][no l10n impact]
Attached patch Fix - v3 (obsolete) β€” β€” Splinter Review
This patch takes care of persisting at the right moment, with the right ids, in the right dialogs. I've tested this on mac, I'd appreciate testing on windows to see if the dialog flickers at any moment.
Attachment #358611 - Attachment is obsolete: true
Attachment #371644 - Attachment is obsolete: true
Attachment #547130 - Flags: review?(bv1578)
I'm going to take this from the blocking list, although very annoying I think we could live without for 1.0. Since a patch is up that should be irrelevant anyway.
Flags: blocking-calendar1.0+
Whiteboard: [not needed beta][no l10n impact] → [no l10n impact]
Attached patch Fix - v4 (obsolete) β€” β€” Splinter Review
Adds one more css rule to ensure no flickering.
Attachment #547130 - Attachment is obsolete: true
Attachment #547150 - Flags: review?(bv1578)
Attachment #547130 - Flags: review?(bv1578)
Attached patch Fix - v4 β€” β€” Splinter Review
Oops, forgot to qref
Attachment #547150 - Attachment is obsolete: true
Attachment #547335 - Flags: review?(bv1578)
Attachment #547150 - Flags: review?(bv1578)
Comment on attachment 547335 [details] [diff] [review] Fix - v4 Philipp, it seems that on Windows 7 the patch has several issues. 1. the position is not stored. Every time the dialog is being opened, the position is the top left corner even when changing the position before close the dialog; 2. every time the dialog is being closed and reopened, the size becomes smaller (the width becomes 16 pixels smaller and the height 38 pixels smaller). The task and event dialogs store independent sizes but opening and closing the dialog e.g. for six times, the size becomes so small that the description text box disappears; 3. the patch basically covers the bug 585974 but not the minimum size problem as reported in comment 7 (the bug summary) i.e doesn't exist a minimum size when resizing and any minimum size doesn't get restored when the dialog is being closed with a minor size. About this last point, IMHO Stefan (comment 10) is right, because if the user wants to reduce the dialog to a small size, he should be allowed to do it. When Lightning runs for the first time, the code opens the dialog to a correct size and then the dialog becomes very small only when the user explicitly reduces the size, so he/she shouldn't be confused by a very small dialog (comment 7). Moreover, no dialog on Thunderbird, and Firefox as well, has a minimum size (apart from dialogs with fixed size). I'm not able to reproduce the flickering, even without the css rule, but I'm not sure if I've completely understood the problem. Philipp, could you please explain it in more details?
Attachment #547335 - Flags: review?(bv1578) → review-
Before that Bug 585974 was marked as a duplicate of this bug, I had written a patch for that bug (hence it doesn't consider the minimum size/scrollbar problem). The patch stores a persisting 8-size array with positions and sizes for two dialogs. On opening, the code reads the array and on closing the array is written with the last values. At the beginning it seemed to me too complicated for a persistence problem, but now it seems even too simple. Probably I had missed something ;-) I attach it, as it was that time, not for asking for review but maybe it has some element for solving issues in patch Fix - v4.
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
Component: General → Dialogs
QA Contact: general → dialogs
Target Milestone: 1.0b1 → ---
Status: ASSIGNED → RESOLVED
Closed: 16 years ago5 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: