If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

"ASSERTION: Must be able to access currentInner" with Google custom search widget

RESOLVED FIXED in mozilla1.9.2a1

Status

()

Core
XPConnect
RESOLVED FIXED
9 years ago
8 years ago

People

(Reporter: Jesse Ruderman, Assigned: mrbkap)

Tracking

({assertion, regression, verified1.9.1})

Trunk
mozilla1.9.2a1
assertion, regression, verified1.9.1
Points:
---

Firefox Tracking Flags

(status1.9.1 .4-fixed)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

9 years ago
Created attachment 354860 [details]
partially-reduced testcase

###!!! ASSERTION: Must be able to access currentInner!: 'nsContentUtils::CanCallerAccess(currentInner)', file /Users/jruderman/central/dom/src/base/nsDOMClassInfo.cpp, line 5256

This assertion was added in bug 467210.

Security-sensitive for now because this is an assertion failure in code related to security.

Comment 1

9 years ago
I think I saw this assertion also when running mochitest (or chrome or browser-chrome).
(Assignee)

Comment 2

9 years ago
(In reply to comment #1)
> I think I saw this assertion also when running mochitest (or chrome or
> browser-chrome).

NS_ASSERTION is so useless because it's impossible to notice if you add an assertion during mochitests.

So, I think this might be OK actually. What's happening here is that we're resolving the (allAccess) location property on a foreign frame. This, in turn, defines the Location constructor on that foreign frame. In the process of creating the Location constructor, we create it with the bugzilla script still on the call stack, hitting the assertion.

This is okay, though, because the calling script can't access the constructor, and we do another check in BaseStubConstructor. I think we should be able to remove the assertion or push the window's context in nsWindowSH::GlobalResolve.

Comment 3

9 years ago
(In reply to comment #2) 
> NS_ASSERTION is so useless because it's impossible to notice if you add an
> assertion during mochitests.
I pretty often log the output of mochitest and grep assertions.
NS_ABORT_IF_FALSE is the new NS_ASSERTION.  If you want to assert something, use that -- it can't be ignored.

Comment 5

9 years ago
pretty off topic, but running tests doesn't assert too much nowadays,
especially chrome and browser-chrome. There are few assertions which shouldn't
be assertions but warnings and other things we should just fix.
IIRC the assertion count when running the whole mochitest has dropped to 1/3 what
it used to be still some time ago.
I'm able to reproduce this type of assertion while running a crashtest within widgets/src/cocoa. See bug 471978.
(Assignee)

Comment 7

9 years ago
Created attachment 355486 [details] [diff] [review]
So, comme ça?
[Checkin: Comment 9 & 12]
Assignee: nobody → mrbkap
Status: NEW → ASSIGNED
Attachment #355486 - Flags: review?(bent.mozilla)
Attachment #355486 - Flags: review?(bent.mozilla) → review+
Comment on attachment 355486 [details] [diff] [review]
So, comme ça?
[Checkin: Comment 9 & 12]

Works for me!
(Assignee)

Updated

9 years ago
Attachment #355486 - Flags: superreview?(jst)

Updated

9 years ago
Attachment #355486 - Flags: superreview?(jst) → superreview+
(Assignee)

Comment 9

9 years ago
http://hg.mozilla.org/mozilla-central/rev/3153bca51559
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Blocks: 471978, 503547
Flags: wanted1.9.1.x?
OS: Mac OS X → All
Hardware: x86 → All
Whiteboard: [needs 1.9.1.x landing]
Target Milestone: --- → mozilla1.9.2a1
Not a security bug given the fix and comment 2, but if still wanted on 1.9.1 a motivated developer needs to request approval on the patch.
Group: core-security
Flags: wanted1.9.1.x?
Attachment #355486 - Flags: approval1.9.1.3?
Comment on attachment 355486 [details] [diff] [review]
So, comme ça?
[Checkin: Comment 9 & 12]

Approved for 1.9.1.4, a=dveditz for release-drivers
Attachment #355486 - Flags: approval1.9.1.3? → approval1.9.1.4+
Comment on attachment 355486 [details] [diff] [review]
So, comme ça?
[Checkin: Comment 9 & 12]


http://hg.mozilla.org/releases/mozilla-1.9.1/rev/a987674af997
Attachment #355486 - Attachment description: So, comme ça? So, comme ça? → So, comme ça? [Checkin: Comment 9 & 12] So, comme ça? [Checkin: Comment 9 & 12]
status1.9.1: --- → .4-fixed
Whiteboard: [needs 1.9.1.x landing]
Duplicate of this bug: 471978
No longer blocks: 471978
No longer blocks: 503547
Duplicate of this bug: 503547
Verified on 1.9.1 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5pre) Gecko/20091008 Shiretoko/3.5.5pre ID:20091008213747
Keywords: verified1.9.1
You need to log in before you can comment on or make changes to this bug.