Closed
Bug 1005392
Opened 10 years ago
Closed 10 years ago
Find seems to keep documents alive too long
Categories
(Toolkit :: Find Toolbar, defect)
Toolkit
Find Toolbar
Tracking
()
RESOLVED
FIXED
mozilla32
People
(Reporter: smaug, Assigned: smaug)
Details
Attachments
(1 file)
6.16 KB,
patch
|
enndeakin
:
review+
|
Details | Diff | Splinter Review |
It has happened now several times during the last few months that find seems to keep alive a document which has been already navigated away. That increases cycle collection time rather dramatically. I wonder if e10s-fying has caused this? Perhaps we should wrappercache TypeAHeadFind and make it skippable, and mark the owned nodes black during CanSkip. Or release stuff earlier.
Comment 1•10 years ago
|
||
(In reply to Olli Pettay [:smaug] from comment #0) > Perhaps we should wrappercache TypeAHeadFind and make it skippable, and mark > the owned nodes black during CanSkip. I think this would be fine under all circumstances for TypeAheadFind.
Updated•10 years ago
|
OS: Linux → All
Hardware: x86_64 → All
Assignee | ||
Comment 2•10 years ago
|
||
This changes the API behavior a bit, since currentWindow will now return inner window. That feels more correct, since that is where the results live, in the document inside an inner window. The testcase for this is to open a tab, load a bugzilla bug page to it, press ctrl+f, search for 'mozilla', focus location bar and load about:blank. The bug page will show up in the CC graphs. TypeAheadFind code is odd, but this was the simplest change to fix the obvious runtime leak. ReleaseStrongMemberVariables() name isn't perhaps the best, since there is still mWebBrowserFind, which is strong, but that doesn't need to be cleared in this case (it isn't cycle collectable thing) mDidAddObservers is there to prevent adding more observers than needed. This bug is very bad for anyone using find a lot. https://tbpl.mozilla.org/?tree=Try&rev=64137503fa57
Assignee: nobody → bugs
Attachment #8418968 -
Flags: review?(gavin.sharp)
Comment 3•10 years ago
|
||
<gavin> smaug: why is mDidAddObservers needed <smaug> gavin: the API doesn't prevent anyone to re-initialize the thing <smaug> gavin: and observer service keeps adding observers to the list <gavin> smaug: this happens in practice? <smaug> I'm not aware of that <gavin> did you notice this in testing or something, or is it speculative? <smaug> this is speculative <gavin> ok
Updated•10 years ago
|
Attachment #8418968 -
Flags: review?(gavin.sharp) → review?(enndeakin)
Updated•10 years ago
|
Attachment #8418968 -
Flags: review?(enndeakin) → review+
Assignee | ||
Updated•10 years ago
|
Keywords: checkin-needed
Comment 4•10 years ago
|
||
https://hg.mozilla.org/integration/fx-team/rev/07dfcb557d32
Keywords: checkin-needed
Comment 5•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/07dfcb557d32
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
You need to log in
before you can comment on or make changes to this bug.
Description
•