#11601 closed defect (fixed)
Calendar: memory leak when using “next month” buttons
Reported by: | Roberto Mosqueda | Owned by: | bill |
---|---|---|---|
Priority: | high | Milestone: | 1.5.1 |
Component: | Dijit | Version: | 1.5 |
Keywords: | memory leak | Cc: | David Schwartz, [email protected]…, [email protected]…, haysmark |
Blocked By: | Blocking: |
Description (last modified by )
Testing Type: Memory leaks
Widget: dijit.InlineEditBox
Short description: Memory level increases when using “next month” buttons. Once you remove them or reload the site memory level keeps higher.
Steps to Reproduce:
- Open the file dojo-release-1.5.0/dijit/tests/test_InlineEditBox.html with Safari 4.0
- Select a Textbox with a date and click on "next month" button over and over again until arriving to December 2032
- Press F5 or reload the page.
Actual Result: Memory used is not released
Expected Result: Memory level should get reduced once you click on a date or when you refresh
Attachments (2)
Change History (12)
Changed 11 years ago by
Attachment: | inlineEditbox.GIF added |
---|
comment:1 Changed 11 years ago by
Cc: | [email protected]… removed |
---|---|
Component: | General → Dijit |
Description: | modified (diff) |
Owner: | anonymous deleted |
comment:2 Changed 11 years ago by
Summary: | Memory level increases when using “next month” buttons → Calendar: memory leak when using “next month” buttons |
---|
comment:3 Changed 11 years ago by
Cc: | haysmark added |
---|
Changed 10 years ago by
Attachment: | 11601.patch added |
---|
Refs #11601. Reduces the majority of the Calendar memory leak.
comment:5 Changed 10 years ago by
Per a comment in Calendar, I moved the code where we set the typematic from populateGrid to buildRendering. Because the next month and next year buttons are never removed from the interface, there is no sense in binding them every time the Calendar is updated.
comment:6 Changed 10 years ago by
Milestone: | tbd → 1.6 |
---|---|
Owner: | set to bill |
Great, thanks, I'll check that in. Looks to me like the leak is completely fixed.
comment:7 Changed 10 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:8 Changed 10 years ago by
Could you also check this in to the 1.5 branch? Also, trac shows the actual change is very large, is this mostly whitespace changes?
comment:9 Changed 10 years ago by
comment:10 Changed 10 years ago by
Milestone: | 1.6 → 1.5.1 |
---|
OK, I backported it to the 1.5 branch.
I think trac showing the change as large is just something weird with trac's diff algorithm? It shows up as a small diff when I compare the two revisions in eclipse. I didn't adjust the spacing at all.
Is it happening in test_Calendar.html too?