Closed
Bug 292903
Opened 21 years ago
Closed 21 years ago
the bfcache should save and restore all resolved standard objects
Categories
(Core :: JavaScript Engine, defect, P3)
Core
JavaScript Engine
Tracking
()
RESOLVED
FIXED
mozilla1.8beta3
People
(Reporter: brendan, Assigned: brendan)
References
Details
(Keywords: js1.5)
Attachments
(2 files)
|
21.34 KB,
patch
|
shaver
:
review+
brendan
:
approval1.8b3+
|
Details | Diff | Splinter Review |
|
3.65 KB,
patch
|
bryner
:
review+
jst
:
superreview+
|
Details | Diff | Splinter Review |
bryner's code in nsGlobalWindow::SaveWindowState uses CopyJSProperties which
uses JS_Enumerate to list the enumerable ids in the window object. What we
really want are the enumerables, which include DOM standard objects, plus the
non-enumerable standard core language classes and utilities (Date, parseInt, etc.).
This gives the desired transparency, so users can decorate String.prototype,
e.g., and find the added methods on fast-back.
Since the DOM code uses JS_ResolveStandardClass to lazily initialize the
standard objects, we want a JS_EnumerateResolvedStandardClasses API. I'll
change the bfcache code to use this new API, as well as add the API, all under
this bug, if that's ok.
/be
Updated•21 years ago
|
Flags: testcase-
| Assignee | ||
Comment 1•21 years ago
|
||
Easy enough to write a testcase. You could even automate the navigation using
an iframe and theFrame.history.back(), etc.
/be
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla1.8beta3
Updated•21 years ago
|
Flags: testcase- → testcase?
| Assignee | ||
Comment 2•21 years ago
|
||
This patch fixes XML-related class name resolution to (a) use
standard_class_atoms not standard_class_names, so they're included in
enumerations; (b) split out a few init hooks for the QName variants, per bug
295606. It also implements JS_EnumerateResolvedStandardClasses, as promised.
Next patch will use that API from the bfcache code.
/be
Attachment #186362 -
Flags: review?(shaver)
Comment 3•21 years ago
|
||
Comment on attachment 186362 [details] [diff] [review]
proposed fix
r=shaver.
Attachment #186362 -
Flags: review?(shaver) → review+
| Assignee | ||
Comment 4•21 years ago
|
||
Attachment #186446 -
Flags: superreview?(jst)
Attachment #186446 -
Flags: review?(bryner)
| Assignee | ||
Comment 5•21 years ago
|
||
Comment on attachment 186362 [details] [diff] [review]
proposed fix
I checked this in earlier today.
/be
Attachment #186362 -
Flags: approval1.8b3+
Comment 6•21 years ago
|
||
Comment on attachment 186446 [details] [diff] [review]
patch to use the new JS API
sr=jst
Attachment #186446 -
Flags: superreview?(jst) → superreview+
Comment 7•21 years ago
|
||
Comment on attachment 186446 [details] [diff] [review]
patch to use the new JS API
r=me if you're sure |props| will always be non-null under normal conditions
Attachment #186446 -
Flags: review?(bryner) → review+
| Assignee | ||
Comment 8•21 years ago
|
||
(In reply to comment #7)
> (From update of attachment 186446 [details] [diff] [review] [edit])
> r=me if you're sure |props| will always be non-null under normal conditions
Null or false return from a JS API that takes a cx first argument and allocates
memory or does anything that might throw a JS error/exception means that the API
call failed, always.
Checked in, without some printfs I added to verify it worked, and with a fix to
jsapi.c, to avoid resolving all the not-yet-resolved standard class names!
/be
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Updated•20 years ago
|
Flags: in-testsuite? → in-testsuite-
You need to log in
before you can comment on or make changes to this bug.
Description
•