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)
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•20 years ago
|
Blocks: splitwindows
Keywords: regression
Comment 1•20 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•20 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•20 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•20 years ago
|
Attachment #192039 -
Flags: superreview?(bryner)
Attachment #192039 -
Flags: review?(mrbkap)
Updated•20 years ago
|
Attachment #192039 -
Flags: superreview?(bryner) → superreview+
Comment 4•20 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•20 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•20 years ago
|
||
Comment on attachment 192039 [details] [diff] [review]
Fix.
Requesting approval for this regression fix.
Attachment #192039 -
Flags: approval1.8b4?
Updated•20 years ago
|
Flags: blocking1.8b4? → blocking1.8b4+
Updated•20 years ago
|
Attachment #192039 -
Flags: approval1.8b4? → approval1.8b4+
| Assignee | ||
Comment 7•20 years ago
|
||
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Updated•7 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•