Closed
Bug 420585
Opened 16 years ago
Closed 16 years ago
Defining setters for properties of the global object doesn't work
Categories
(Core :: XPConnect, defect, P2)
Core
XPConnect
Tracking
()
RESOLVED
FIXED
mozilla1.9beta5
People
(Reporter: ancestor.ak, Assigned: mrbkap)
References
Details
(Keywords: regression, testcase)
Attachments
(2 files)
220 bytes,
text/html
|
Details | |
4.39 KB,
patch
|
jst
:
review+
jst
:
superreview+
|
Details | Diff | Splinter Review |
The following works as expected in the shell: < var y; < __defineSetter__('x', function(val) { y = val }); < x = 3; < y > 3 However, it fails in an apparently identical testcase, the setter never gets called. Regressed between 2008-03-01 00:16 and 2008-03-01 03:10: http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1204359360&maxdate=1204369859
Updated•16 years ago
|
Flags: blocking1.9?
Assignee | ||
Comment 1•16 years ago
|
||
This is *so* mine.
Assignee: general → nobody
Component: JavaScript Engine → XPConnect
OS: Windows XP → All
Priority: -- → P2
QA Contact: general → xpconnect
Hardware: PC → All
Target Milestone: --- → mozilla1.9beta4
Assignee | ||
Updated•16 years ago
|
Assignee: nobody → mrbkap
Assignee | ||
Comment 2•16 years ago
|
||
We need to propagate the getters and setters onto the inner object. There is now some code duplication between XPCWrapper::AddProperty and XPCWrapper::NewResolve, which I can fix if you think it's worth it.
Attachment #306951 -
Flags: superreview?(jst)
Attachment #306951 -
Flags: review?(jst)
Updated•16 years ago
|
Flags: blocking1.9? → blocking1.9+
Updated•16 years ago
|
Attachment #306951 -
Flags: superreview?(jst)
Attachment #306951 -
Flags: superreview+
Attachment #306951 -
Flags: review?(jst)
Attachment #306951 -
Flags: review+
Comment 3•16 years ago
|
||
Brendan: blocking1.9 with a target milestone of beta4 means that this blocks shipment of beta4. If you don't think that's necessary, please change the TM to "mozilla1.9".
Assignee | ||
Comment 4•16 years ago
|
||
Oops, that's my fault.
Target Milestone: mozilla1.9beta4 → mozilla1.9
Assignee | ||
Updated•16 years ago
|
Attachment #306951 -
Flags: approval1.9?
Reporter | ||
Comment 5•16 years ago
|
||
Comment on attachment 306951 [details] [diff] [review] Fix This bug is blocking1.9+, approval is not needed.
Attachment #306951 -
Flags: approval1.9?
Assignee | ||
Comment 6•16 years ago
|
||
Fix checked into trunk.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Updated•16 years ago
|
Target Milestone: mozilla1.9 → mozilla1.9beta5
Comment 7•16 years ago
|
||
The if (!isXOW) sequence in XPCWrapper::AddProperty() seems to allow a situation where |v| is used in OBJ_DEFINE_PROPERTY uninitialized. I am hitting this case while using firebug 1.2 with a recent nightly build.
Comment 8•16 years ago
|
||
(In reply to comment #7) > The if (!isXOW) sequence in XPCWrapper::AddProperty() seems to allow a > situation where |v| is used in OBJ_DEFINE_PROPERTY uninitialized. Obvious bug, sorry I missed it -- please file new and cite it here? /be
Comment 9•16 years ago
|
||
Crowder: I missed your setting the new bug as blocked by this one, but that is backwards. The reason is that if one were cherry-picking fixes onto a release branch, one would not want just this bug -- one would want to see that it was blocked by a newer bug, and consider taking that bug's patch too. /be
Comment 10•16 years ago
|
||
Sorry, assumed "Clone This Bug" would do the right thing, and did not examine dependencies closely enough.
You need to log in
before you can comment on or make changes to this bug.
Description
•