Closed Bug 303420 Opened 19 years ago Closed 19 years ago

global scope polluter (element by id in global scope) is missing

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.8beta4

People

(Reporter: sync2d, Assigned: jst)

References

Details

(Keywords: fixed1.8, regression)

Attachments

(1 file)

I see no global scope polluter (bug 256932) in recent trunk builds.
This seems to be a regression from bug 296639.

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b4) Gecko/20050803 Firefox/1.0+
data:text/html,<script id=x>alert(x);</script>
  => "Error: x is not defined" in JS console
javascript: alert(window.__proto__.__proto__);
  => alerts "[object Object]"

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b4) Gecko/20050730 Firefox/1.0+
data:text/html,<script id=x>alert(x);</script>
  => alerts "[object HTMLScriptElement]"
javascript: alert(window.__proto__.__proto__);
  => alerts "[object Global Scope Polluter]"
Summary: global scope polluer (element by id in global scope) is missing → global scope polluter (element by id in global scope) is missing
Blocks: splitwindows
Keywords: regression
confirmed, the creation of the GlobalScopePolluter is failing.  js_NewObject fails because 
GetClassPrototype returns false.  I think this may be impacting fastback as well.
Assignee: general → jst
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.8b4?
Yup, the gsp is busted. I made it work on the splitwindow branch, but I might
have broken it again before it landed on the trunk. Investigating.
Status: NEW → ASSIGNED
OS: Windows 98 → All
Hardware: PC → All
Target Milestone: --- → mozilla1.8beta4
Attached patch Fix.Splinter Review
This was failing because we end up doing a security check in the middle of
installing the global scope polluter, and becasue we do that while setting up a
new inner window we end up doing the security check before the new inner window
has any principals, so the security check fails. This makes us not do security
checks while we're in the middle of the window inintialization by ensuring that
mIsInitialized set set to false during the whole window init function, and also
makes sure that we don't ever use a context that hasn't been fully initalized
(since we won't do security checks in some cases if a context is not
initialized).
Attachment #192039 - Flags: superreview?(bryner)
Attachment #192039 - Flags: review?(mrbkap)
Attachment #192039 - Flags: superreview?(bryner) → superreview+
Comment on attachment 192039 [details] [diff] [review]
Fix.

r=me
Attachment #192039 - Flags: superreview?(bryner)
Attachment #192039 - Flags: superreview+
Attachment #192039 - Flags: review?(mrbkap)
Attachment #192039 - Flags: review+
Comment on attachment 192039 [details] [diff] [review]
Fix.

oops, I think I messed up the review flags earlier. sr=me.
Attachment #192039 - Flags: superreview?(bryner) → superreview+
Comment on attachment 192039 [details] [diff] [review]
Fix.

Requesting approval for this regression fix.
Attachment #192039 - Flags: approval1.8b4?
Flags: blocking1.8b4? → blocking1.8b4+
Attachment #192039 - Flags: approval1.8b4? → approval1.8b4+
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Fixed on the trunk before we branched for 1.8.
Keywords: fixed1.8
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.