ASSERTION: Wrong scope, this is really bad!: 'JS_GetGlobalForObject(cx, obj) == newScope'

RESOLVED FIXED in mozilla1.9.2a1

Status

()

P2
normal
RESOLVED FIXED
9 years ago
8 years ago

People

(Reporter: aakashd, Assigned: peterv)

Tracking

Trunk
mozilla1.9.2a1
Points:
---
Bug Flags:
blocking1.9.2 +

Firefox Tracking Flags

(status1.9.2 beta1-fixed, status1.9.1 wontfix)

Details

Attachments

(3 attachments)

(Reporter)

Description

9 years ago
build id: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre)
Gecko/20090706 Minefield/3.6a1pre ID:20090706143743

Use the following in-line JS into the location bar on a debug build of trunk document.write("<head></head><body></body>");


This is referenced off of bug 465752 and the JS listed there by bz

Comment 1

9 years ago
I can reproduce.

###!!! ASSERTION: Wrong scope, this is really bad!: 'JS_GetGlobalForObject(cx, obj) == newScope', file /Users/jruderman/central/content/base/src/nsDocument.cpp, line 3566
Peter, Blake, this looks related to stuff you've looked into recently... and which might want on branches.

It would be really nice to have a regression range here to make sure we _don't_ land this on branch all-unknowing.
Flags: blocking1.9.2?
Peter, could you have a look at this one? I think it'd be good to at least understand more about this for 1.9.2...
Assignee: nobody → peterv
Flags: blocking1.9.2? → blocking1.9.2+
Keywords: regressionwindow-wanted
Priority: -- → P2
(Assignee)

Comment 4

9 years ago
Hmm, we check the scope before OpenCommon reparents the wrapper. We somehow need to relax this assertion in that case.
(Assignee)

Comment 5

9 years ago
The assertion was added in bug 499910, so pretty sure that's where the regression comes from.
Blocks: 499910
Status: NEW → ASSIGNED
Keywords: regressionwindow-wanted
(Assignee)

Comment 7

9 years ago
Created attachment 393817 [details] [diff] [review]
v1 (diff -w)
Attachment #393817 - Flags: superreview?(jst)
Attachment #393817 - Flags: review?(jst)

Updated

9 years ago
Attachment #393817 - Flags: superreview?(jst)
Attachment #393817 - Flags: superreview+
Attachment #393817 - Flags: review?(jst)
Attachment #393817 - Flags: review+
(Assignee)

Comment 8

9 years ago
http://hg.mozilla.org/mozilla-central/rev/ffc0bbb9ccb4
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
OS: Mac OS X → All
Hardware: x86 → All
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.2a1
(Assignee)

Updated

9 years ago
status1.9.2: --- → beta1-fixed
(Assignee)

Updated

9 years ago
Duplicate of this bug: 517711
(Assignee)

Comment 10

9 years ago
Created attachment 422532 [details] [diff] [review]
v1 (1.9.1 branch version)

This is a debug only patch, removing a false-positive occurrence of an assertion. The assertion is pretty important, so I think it'd be good to resolve this on the branch too so we avoid confusion (see bug 517711).
Attachment #422532 - Flags: approval1.9.1.8?
Comment on attachment 422532 [details] [diff] [review]
v1 (1.9.1 branch version)

Approved for 1.9.1.8, a=dveditz for release-drivers
Attachment #422532 - Flags: approval1.9.1.8? → approval1.9.1.8+
peterv: please land this today if it's going to make 1.9.1.8, otherwise it'll have to go into a future release.
Attachment #422532 - Flags: approval1.9.1.8+ → approval1.9.1.9?
Comment on attachment 422532 [details] [diff] [review]
v1 (1.9.1 branch version)

next release it is: approval1.9.1.8 removed.
Attachment #422532 - Flags: approval1.9.1.9?
Comment on attachment 422532 [details] [diff] [review]
v1 (1.9.1 branch version)

I shouldn't have moved the request from 1.9.1.8 to 1.9.1.9 -- it's possible it missed 1.9.1.8 because you don't really want it anymore. Please re-request approval if you do still want this on the 1.9.1 branch
blocking1.9.1: --- → ?
status1.9.1: --- → wanted
blocking1.9.1: ? → needed
Guess we're wontfixing this for the 1.9.1 branch
blocking1.9.1: needed → ---
status1.9.1: wanted → wontfix
You need to log in before you can comment on or make changes to this bug.