Closed Bug 654770 Opened 9 years ago Closed 9 years ago
"ASSERTION: Won't check if this is chrome
..." with accessibility enabled
###!!! 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
Btw, the assertion condition and message no longer match.
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.
I don't know how to test this - I mean I don't even know how to get the assertion.
Assignee: nobody → Olli.Pettay
Comment on attachment 530090 [details] [diff] [review] patch Actually, I'll fix also other cases in this bug.
I'll fix the assertion text elsewhere. The a11y case is the only one which may change the behavior (back to what it was).
(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?
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+
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
(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.