Note: There are a few cases of duplicates in user autocompletion which are being worked on.

"ASSERTION: Won't check if this is chrome..." with accessibility enabled

RESOLVED FIXED

Status

()

Core
Disability Access APIs
P1
normal
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: Jesse Ruderman, Assigned: smaug)

Tracking

(Blocks: 1 bug, {assertion, regression})

Trunk
x86
Linux
assertion, regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

6 years ago
###!!! ASSERTION: Won't check if this is chrome, you want to set aWantsUntrusted to PR_FALSE or make the aWantsUntrusted explicit by making optional_argc non-zero.: '!aWantsUntrusted || optional_argc > 1', file ../../../../content/base/src/nsDocument.cpp, line 6298

nsDocument::AddEventListener [nsDocument.cpp:6300]
nsRootAccessible::AddEventListeners [nsRootAccessible.cpp:267]
nsDocAccessible::Init [nsDocAccessible.cpp:614]
nsAccDocManager::CreateDocOrRootAccessible [nsAccDocManager.cpp:456]
nsAccDocManager::GetDocAccessible [nsAccDocManager.cpp:81]
nsApplicationAccessible::CacheChildren [nsApplicationAccessible.cpp:423]
nsAccessible::EnsureChildren [nsAccessible.cpp:3163]
nsAccDocManager::GetDocAccessible [nsAccDocManager.cpp:76]
nsAccessibilityService::ContentRemoved [nsAccessibilityService.cpp:542]
nsCSSFrameConstructor::ContentRemoved [nsCSSFrameConstructor.cpp:7464]
nsCSSFrameConstructor::RecreateFramesForContent [nsCSSFrameConstructor.cpp:9109]
nsCSSFrameConstructor::ProcessRestyledFrames [nsCSSFrameConstructor.cpp:7982]
nsCSSFrameConstructor::RestyleElement [nsCSSFrameConstructor.cpp:8064]
mozilla::css::RestyleTracker::ProcessOneRestyle [RestyleTracker.cpp:156]
mozilla::css::RestyleTracker::ProcessRestyles [RestyleTracker.cpp:222]
nsCSSFrameConstructor::ProcessPendingRestyles [nsCSSFrameConstructor.cpp:11616]
PresShell::FlushPendingNotifications [nsPresShell.cpp:4791]
nsRefreshDriver::Notify [nsRefreshDriver.cpp:366]
nsTimerImpl::Fire [nsTimerImpl.cpp:428]
nsTimerEvent::Run [nsTimerImpl.cpp:522]
nsThread::ProcessNextEvent [nsThread.cpp:618]
NS_ProcessNextEvent_P [nsThreadUtils.cpp:250]
mozilla::ipc::MessagePump::Run [MessagePump.cpp:110]
MessageLoop::RunInternal [message_loop.cc:219]
MessageLoop::RunHandler [message_loop.cc:203]
MessageLoop::Run [message_loop.cc:175]
nsBaseAppShell::Run [nsBaseAppShell.cpp:191]
nsAppStartup::Run [nsAppStartup.cpp:224]
XRE_main [nsAppRunner.cpp:3682]
main [nsBrowserApp.cpp:158]
libc.so.6 + 0x15dec

Probably a regression from mozilla-central changeset f0ad024522bb:
user:        Olli Pettay
date:        Wed May 04 17:13:28 2011 +0300
summary:     Bug 613634, make the 3rd paramater of add/removeEventListener optional, r=sicking

I noticed this bug because I hit it during fuzzing, but it also happens on Tinderbox (without turning Tinderbox orange, see bug 571613).

Before (does not hit the assertion):
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1304521011.1304524426.15516.gz&fulltext=1

After (hits the assertion):
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1304526794.1304530259.17266.gz&fulltext=1
(Reporter)

Comment 1

6 years ago
Btw, the assertion condition and message no longer match.
(Assignee)

Comment 2

6 years ago
Uh, I need to go through even more code.

AddEventListener(NS_ConvertASCIItoUTF16(*e), this, PR_TRUE, PR_TRUE, 1);
should now pass 2 as the last parameter.
(Assignee)

Comment 3

6 years ago
Created attachment 530090 [details] [diff] [review]
patch

I don't know how to test this - I mean I don't even know how to get
the assertion.
Assignee: nobody → Olli.Pettay
Attachment #530090 - Flags: review?(bolterbugz)
(Assignee)

Comment 4

6 years ago
Comment on attachment 530090 [details] [diff] [review]
patch

Actually, I'll fix also other cases in this bug.
Attachment #530090 - Flags: review?(bolterbugz)
(Assignee)

Comment 5

6 years ago
Created attachment 530104 [details] [diff] [review]
patch

I'll fix the assertion text elsewhere.

The a11y case is the only one which may change the behavior (back to what it was).
Attachment #530090 - Attachment is obsolete: true
Attachment #530104 - Flags: review?(jonas)
(Assignee)

Updated

6 years ago
Priority: -- → P1
(In reply to comment #5)
> Created attachment 530104 [details] [diff] [review] [review]

> The a11y case is the only one which may change the behavior (back to what it
> was).

Can you explain this a bit more?
(Assignee)

Comment 7

6 years ago
Oh, actually, since it a11y passes PR_TRUE, I didn't break even that.
Bug 613634 just causes the assertion.

Btw, why does a11y listen for untrusted events?
Attachment #530104 - Flags: review?(jonas) → review+
(Assignee)

Comment 8

6 years ago
http://hg.mozilla.org/mozilla-central/rev/8ccb9dff65d7
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED

Comment 9

6 years ago
(In reply to comment #7)
> Oh, actually, since it a11y passes PR_TRUE, I didn't break even that.
> Bug 613634 just causes the assertion.
> 
> Btw, why does a11y listen for untrusted events?

XBL bindings fires events for us like XUL radio fires RadioStateChange event. Based on that we fire a11y events. If I get right these are untrusted events (or they were :) ).
You need to log in before you can comment on or make changes to this bug.