Closed Bug 303420 Opened 20 years ago Closed 20 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+
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: 20 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.

Attachment

General

Created:
Updated:
Size: