Closed Bug 471560 Opened 13 years ago Closed 13 years ago
"ASSERTION: Must be able to access current
Inner" with Google custom search widget
###!!! 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.
I think I saw this assertion also when running mochitest (or chrome or browser-chrome).
(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.
(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.
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: nobody → mrbkap
Status: NEW → ASSIGNED
Attachment #355486 - Flags: review?(bent.mozilla)
13 years ago
Attachment #355486 - Flags: review?(bent.mozilla) → review+
Comment on attachment 355486 [details] [diff] [review] So, comme ça? [Checkin: Comment 9 & 12] Works for me!
Attachment #355486 - Flags: superreview?(jst)
Attachment #355486 - Flags: superreview?(jst) → superreview+
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
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.
Comment on attachment 355486 [details] [diff] [review] So, comme ça? [Checkin: Comment 9 & 12] Approved for 22.214.171.124, a=dveditz for release-drivers
Attachment #355486 - Flags: approval126.96.36.199? → approval188.8.131.52+
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]
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:184.108.40.206pre) Gecko/20091008 Shiretoko/3.5.5pre ID:20091008213747
You need to log in before you can comment on or make changes to this bug.