Closed
Bug 394195
Opened 17 years ago
Closed 5 years ago
Dialogs need a scroll bar or minimum height/width
Categories
(Calendar :: Dialogs, defect)
Calendar
Dialogs
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)
8.38 KB,
patch
|
Fallen
:
review+
|
Details | Diff | Splinter Review |
32.05 KB,
image/jpeg
|
Details | |
5.80 KB,
patch
|
bv1578
:
review-
|
Details | Diff | Splinter Review |
6.63 KB,
patch
|
Details | Diff | Splinter Review |
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.
Updated•17 years ago
|
Component: General → Theme
Product: Calendar → Firefox
Target Milestone: --- → Firefox 3
Comment 1•17 years ago
|
||
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
Reporter | ||
Comment 2•16 years ago
|
||
Assignee | ||
Updated•16 years ago
|
Attachment #343384 -
Flags: review?(philipp) → review+
Assignee | ||
Comment 3•16 years ago
|
||
Looks good, will take care of checkin tomorrow or tuesday. If someone wants to take over, please do so
r=philipp
Keywords: checkin-needed
Updated•16 years ago
|
Summary: [Proto] Dialogs doesn't persist width and height set by user → Dialogs don't persist width and height set by user
Comment 4•16 years ago
|
||
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
Updated•16 years ago
|
Keywords: checkin-needed
Updated•16 years ago
|
Target Milestone: --- → 1.0
Reporter | ||
Comment 5•16 years ago
|
||
-> FIXED.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Comment 6•16 years ago
|
||
Comment 7•16 years ago
|
||
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 → ---
Reporter | ||
Updated•16 years ago
|
Assignee: ssitter → nobody
Assignee | ||
Comment 8•16 years ago
|
||
I think this is a serious UI issue, especially for new users. We should rethink this before 1.0
Flags: blocking-calendar1.0?
Updated•16 years ago
|
Flags: blocking-calendar1.0? → blocking-calendar1.0+
Updated•16 years ago
|
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 | ||
Updated•16 years ago
|
Assignee: nobody → daniel.boelzle
Assignee | ||
Comment 9•16 years ago
|
||
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)
Assignee | ||
Updated•16 years ago
|
Whiteboard: [needs review]
Reporter | ||
Comment 10•16 years ago
|
||
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)
Assignee | ||
Comment 11•16 years ago
|
||
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]
Updated•16 years ago
|
Whiteboard: [needs decision] → [needs decision][not needed beta]
Updated•16 years ago
|
Whiteboard: [needs decision][not needed beta] → [needs decision][not needed beta][no l10n impact]
Updated•16 years ago
|
Whiteboard: [needs decision][not needed beta][no l10n impact] → [not needed beta][no l10n impact][needs decision]
Assignee | ||
Comment 12•16 years ago
|
||
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.
Comment 13•16 years ago
|
||
(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.
Updated•14 years ago
|
Whiteboard: [not needed beta][no l10n impact][needs decision] → [not needed beta][no l10n impact]
Assignee | ||
Comment 15•14 years ago
|
||
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)
Assignee | ||
Comment 16•14 years ago
|
||
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]
Assignee | ||
Comment 17•14 years ago
|
||
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)
Assignee | ||
Comment 19•14 years ago
|
||
Oops, forgot to qref
Attachment #547150 -
Attachment is obsolete: true
Attachment #547335 -
Flags: review?(bv1578)
Attachment #547150 -
Flags: review?(bv1578)
Comment 20•14 years ago
|
||
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-
Comment 21•14 years ago
|
||
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.
Assignee | ||
Comment 22•13 years ago
|
||
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
Updated•13 years ago
|
Component: General → Dialogs
QA Contact: general → dialogs
Updated•13 years ago
|
Target Milestone: 1.0b1 → ---
Updated•5 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 16 years ago → 5 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•