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)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
FIXED
mozilla1.8beta4
People
(Reporter: sync2d, Assigned: jst)
References
Details
(Keywords: fixed1.8, regression)
Attachments
(1 file)
8.55 KB,
patch
|
mrbkap
:
review+
bryner
:
superreview+
cbeard
:
approval1.8b4+
|
Details | Diff | Splinter Review |
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
Updated•19 years ago
|
Blocks: splitwindows
Keywords: regression
Comment 1•19 years ago
|
||
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?
Assignee | ||
Comment 2•19 years ago
|
||
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
Assignee | ||
Comment 3•19 years ago
|
||
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).
Assignee | ||
Updated•19 years ago
|
Attachment #192039 -
Flags: superreview?(bryner)
Attachment #192039 -
Flags: review?(mrbkap)
Updated•19 years ago
|
Attachment #192039 -
Flags: superreview?(bryner) → superreview+
Comment 4•19 years ago
|
||
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 5•19 years ago
|
||
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+
Assignee | ||
Comment 6•19 years ago
|
||
Comment on attachment 192039 [details] [diff] [review] Fix. Requesting approval for this regression fix.
Attachment #192039 -
Flags: approval1.8b4?
Updated•19 years ago
|
Flags: blocking1.8b4? → blocking1.8b4+
Updated•19 years ago
|
Attachment #192039 -
Flags: approval1.8b4? → approval1.8b4+
Assignee | ||
Comment 7•19 years ago
|
||
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•