Closed
Bug 413516
Opened 16 years ago
Closed 16 years ago
Unifinder shows only the last modified event
Categories
(Calendar :: Calendar Frontend, defect)
Calendar
Calendar Frontend
Tracking
(Not tracked)
VERIFIED
FIXED
0.8
People
(Reporter: ssitter, Assigned: Fallen)
References
Details
(Keywords: regression)
Attachments
(1 file)
20.61 KB,
patch
|
michael.buettner
:
review+
|
Details | Diff | Splinter Review |
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12pre) Gecko/2008012209 Calendar/0.8pre Steps to Reproduce: 1. Start Sunbird with new clean profile 2. Create some new events in the near future, e.g. event "A", "B" and "C" 3. Note that all new events are correctly shown in the unifinder 4. Edit one event and rename it, e.g. rename "B" to "X" Actual Results: Unifinder shows only the last modified event - twice. Once with the old value, once with the new value, e.g. "B" and "X". "A" and "C" are not displayed. Expected Results: Unifinder shows the updated events, e.g. "A", "X", "C".
Assignee | ||
Comment 1•16 years ago
|
||
My fault. This blocks, no doubt about it.
Assignee: nobody → philipp
Flags: blocking-calendar0.8+
Assignee | ||
Comment 2•16 years ago
|
||
This takes care of: * Make sure the index map is always rebuilt * Make the unifinder show the correct items * fix the recurrence2Rule warning (bug 413111) * Remove extra LOG() statements * fix selection for one event * Add all tree methods OTOH, this patch undoes the fix in the multiday view to not refresh the view when the date range is not changed. This doesn't quite work and I cannot find out why. Mickey, if you have any ideas feel free to comment.
Attachment #298543 -
Flags: review?(michael.buettner)
Assignee | ||
Comment 3•16 years ago
|
||
Oh, pretend the comma in line 704 of calendar-unifinder.js is removed :)
Comment 4•16 years ago
|
||
Comment on attachment 298543 [details] [diff] [review] Fix unifinder regressions > // Do not change anything if the date range already matches. >- return; >+ // XXX In general it should be possible to return here, but >+ // lightning doesn't like it when first initializing the view. >+ // return; setDateRange() needs to directly or indirectly call refresh() in order to get the layout code running. Early returning from this function in case the dates didn't change still doesn't free us from calling refresh(). That's because the first time we went through this function the calendar views are hidden and won't do anything. The second time we're getting here wont trigger the layout. So, either remove this early out or just call refresh(). Apart from that, the patch looks fine -> r=mickey.
Attachment #298543 -
Flags: review?(michael.buettner) → review+
Assignee | ||
Comment 5•16 years ago
|
||
I'm going to leave the patch as is for now, since the return is commented out. It would be great if we could change the behavior of the views so that there is no flashing and the boxes don't have to be rebuilt. Checked in on HEAD and MOZILLA_1_8_BRANCH -> FIXED
Status: NEW → RESOLVED
Closed: 16 years ago
OS: Windows XP → All
Hardware: PC → All
Resolution: --- → FIXED
Target Milestone: --- → 0.8
Comment 6•16 years ago
|
||
Check this in nightly build 2008012318 -> task is fixed and verified.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•