Closed Bug 575675 Opened 14 years ago Closed 10 years ago

FindChildWithRules aRelevantLinkVisited assertion when loading HTML page with links in XUL iframe

Categories

(Core :: CSS Parsing and Computation, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla35
Tracking Status
blocking2.0 --- -

People

(Reporter: Mardak, Assigned: dbaron)

References

Details

Attachments

(2 files)

Running without --enable-debug seems to work. Taking out the anchor tag avoids this assertion (but then leads to the assertion in bug 575672): http://hg.mozilla.org/users/edward.lee_engineering.uiuc.edu/tabcandy-central/file/da9dfdef8dfe/browser/base/content/tabcandy/tabcandy.html#l12 <a href="http://feedback.mozillalabs.com/forums/56804-tabcandy" target="new"> <div id="feedback" class="bottomButton">give feedback</div> </a> ###!!! ABORT: aRelevantLinkVisited should only be set when we have a separate style: 'aRulesIfVisited || !aRelevantLinkVisited', file /Users/Ed/tabcandy-central/layout/style/nsStyleContext.cpp, line 176 nsStyleContext::FindChildWithRules(nsIAtom const*, nsRuleNode*, nsRuleNode*, int)+0x0000004B [...MacOS/XUL +0x004C9E95] nsStyleSet::GetContext(nsStyleContext*, nsRuleNode*, nsRuleNode*, int, int, nsIAtom*, nsCSSPseudoElements::Type)+0x0000010A [...MacOS/XUL +0x004D07B2] nsStyleSet::ResolveStyleFor(mozilla::dom::Element*, nsStyleContext*)+0x000001D4 [...MacOS/XUL +0x004D1B7C] nsFrameManager::ReResolveStyleContext(nsPresContext*, nsIFrame*, nsIContent*, nsStyleChangeList*, nsChangeHint, nsRestyleHint, int, mozilla::css::RestyleTracker&)+0x000006D8 [...MacOS/XUL +0x002D2734] nsFrameManager::ComputeStyleChangeFor(nsIFrame*, nsStyleChangeList*, nsChangeHint, mozilla::css::RestyleTracker&, int)+0x0000011B [...MacOS/XUL +0x002D352F] nsCSSFrameConstructor::RestyleElement(mozilla::dom::Element*, nsIFrame*, nsChangeHint, mozilla::css::RestyleTracker&, int)+0x00000177 [...MacOS/XUL +0x002908FB] mozilla::css::RestyleTracker::ProcessOneRestyle(mozilla::dom::Element*, nsRestyleHint, nsChangeHint)+0x0000013A [...MacOS/XUL +0x00276262] mozilla::css::RestyleTracker::ProcessRestyles()+0x00000411 [...MacOS/XUL +0x00274E9B] nsCSSFrameConstructor::ProcessPendingRestyles()+0x00000101 [...MacOS/XUL +0x002906B7] PresShell::FlushPendingNotifications(mozFlushType)+0x0000023A [...MacOS/XUL +0x0030CDBE] nsDocument::FlushPendingNotifications(mozFlushType)+0x00000234 [...MacOS/XUL +0x005C8662] nsDocLoader::DocLoaderIsEmpty(int)+0x00000154 [...MacOS/XUL +0x00F2BD42] nsDocLoader::OnStopRequest(nsIRequest*, nsISupports*, unsigned int)+0x000004E4 [...MacOS/XUL +0x00F2D1F2] nsLoadGroup::RemoveRequest(nsIRequest*, nsISupports*, unsigned int)+0x0000033E [...MacOS/XUL +0x00067AA8] nsDocument::DoUnblockOnload()+0x0000015F [...MacOS/XUL +0x005E5A33] nsDocument::UnblockOnload(int)+0x0000011C [...MacOS/XUL +0x005E5B62] nsDocument::DispatchContentLoadedEvents()+0x000004C3 [...MacOS/XUL +0x005D4877] nsRunnableMethodImpl<void (nsDocument::*)(), true>::Run()+0x00000065 [...MacOS/XUL +0x005EB983] nsThread::ProcessNextEvent(int, int*)+0x000002A4 [...MacOS/XUL +0x014C85CC] NS_ProcessPendingEvents_P(nsIThread*, unsigned int)+0x00000092 [...MacOS/XUL +0x01454DFF] nsBaseAppShell::NativeEventCallback()+0x000000B5 [...MacOS/XUL +0x012CE19D] nsAppShell::ProcessGeckoEvents(void*)+0x000001F1 [...MacOS/XUL +0x0127FEF9] __CFRunLoopDoSources0+0x0000061B [/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation +0x0003F0FB] __CFRunLoopRun+0x0000042F [/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation +0x0003CBBF] CFRunLoopRunSpecific+0x000001C4 [/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation +0x0003C094] CFRunLoopRunInMode+0x00000061 [/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation +0x0003BEC1] RunCurrentEventLoopInMode+0x00000188 [/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox +0x00034F9C] ReceiveNextEventCommon+0x0000009E [/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox +0x00034C8D] BlockUntilNextEventMatchingListInMode+0x00000051 [/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox +0x00034BD6] _DPSNextEvent+0x0000034F [/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit +0x00048A89] -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]+0x0000009C [/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit +0x000482CA] nsAppShell::ProcessNextNativeEvent(int)+0x00000554 [...MacOS/XUL +0x0127F1D4] nsBaseAppShell::DoProcessNextNativeEvent(int)+0x00000041 [...MacOS/XUL +0x012CD92F] nsBaseAppShell::OnProcessNextEvent(nsIThreadInternal*, int, unsigned int)+0x000000DE [...MacOS/XUL +0x012CDDA4] nsAppShell::OnProcessNextEvent(nsIThreadInternal*, int, unsigned int)+0x0000016A [...MacOS/XUL +0x0127E81C] nsThread::ProcessNextEvent(int, int*)+0x000001A0 [...MacOS/XUL +0x014C84C8] NS_ProcessPendingEvents_P(nsIThread*, unsigned int)+0x00000092 [...MacOS/XUL +0x01454DFF] nsBaseAppShell::NativeEventCallback()+0x000000B5 [...MacOS/XUL +0x012CE19D] nsAppShell::ProcessGeckoEvents(void*)+0x000001F1 [...MacOS/XUL +0x0127FEF9] __CFRunLoopDoSources0+0x0000061B [/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation +0x0003F0FB] __CFRunLoopRun+0x0000042F [/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation +0x0003CBBF] CFRunLoopRunSpecific+0x000001C4 [/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation +0x0003C094] CFRunLoopRunInMode+0x00000061 [/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation +0x0003BEC1] RunCurrentEventLoopInMode+0x00000188 [/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox +0x00034F9C] ReceiveNextEventCommon+0x0000009E [/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox +0x00034C8D] BlockUntilNextEventMatchingListInMode+0x00000051 [/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox +0x00034BD6] _DPSNextEvent+0x0000034F [/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit +0x00048A89] -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]+0x0000009C [/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit +0x000482CA] -[NSApplication run]+0x00000335 [/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit +0x0000A55B] nsAppShell::Run()+0x00000123 [...MacOS/XUL +0x0127EC4B] nsAppStartup::Run()+0x00000094 [...MacOS/XUL +0x00FE2360] XRE_main+0x00002C5E [...MacOS/XUL +0x000203D8] main+0x000002CA [...MacOS/firefox-bin +0x000015F9] start+0x00000036 [...MacOS/firefox-bin +0x0000127A] ###!!! ABORT: aRelevantLinkVisited should only be set when we have a separate style: 'aRulesIfVisited || !aRelevantLinkVisited', file /Users/Ed/tabcandy-central/layout/style/nsStyleContext.cpp, line 176
This issue no longer affects TabCandy as of: http://hg.mozilla.org/users/edward.lee_engineering.uiuc.edu/tabcandy-central/rev/a9971133b85f Leaving this bug open, however, as the assert should probably be looked at.
So... this bug is missing some minor things like steps to reproduce. Care to add those? This assertion firing is pretty bad.
Pulling in the revision just before it was worked around should trigger the assertion on startup (tabcandy.html is loaded into a xul:iframe that sits in a xul:deck that allows swapping between browser and tabcandy). http://hg.mozilla.org/users/edward.lee_engineering.uiuc.edu/tabcandy-central/rev/da9dfdef8dfe This was branched off of mozilla-central, so it should be pullable into an existing mozilla-central debug build: http://hg.mozilla.org/users/edward.lee_engineering.uiuc.edu/tabcandy-central/shortlog/46704
I think you're unclear on "steps to reproduce". What do I need to pull, what do I need to build, and how do I need to run it to trigger the bug? Assume I know absolutely nothing about what this "tabcandy" thing is (which would be a correct assumption).
Easiest would be to clone the repository and update to da9dfdef8dfe http://hg.mozilla.org/users/edward.lee_engineering.uiuc.edu/tabcandy-central so hg clone -u da9dfdef8dfe http://hg.mozilla.org/users/edward.lee_engineering.uiuc.edu/tabcandy-central Make a debug build and run and it'll assert.
I can also try generating a single file patch that should apply against mozilla-central to avoid needing to rebuild firefox. The changes should only affect things in the browser directory, so that might be (much) faster than rebuilding from scratch.
Attached patch super diff to assertion (deleted) — Splinter Review
I applied that diff, copied some random pngs in place of the missing png files, and started the build. No assert. But I think I see how we could hit this assert. Give me a few minutes.
Er, no. I don't see a way this can happen, short of the presshell preference stylesheet not being applied. To hit this assert we have to have a null visited rulenode but have aRelevantLinkVisited set to true in FindChildWithRules. That means that in GetContext, aIsVisitedLink is true and aVisitedRuleNode ends up false. but aIsVisitedLink is set to |data.ContentState() & NS_EVENT_STATE_VISITED| and if that's set we should be picking up the pref :link and :visited rules, which should give us different rulenodes forthe regular and if-visited stylecontext.... I'll try the steps from comment 5.
Note that I _was_ getting the bug 575672 assert.
I followed the steps from comment 5. No assert (once I commented out the assert from bug 575672).
To be clear, I'm on Mac (Leopard) here; using a clean profile.
Ian, you hit the assertion on a clean checkout? The .mozconfig I used was pretty much from MDN: ac_add_options --enable-debug --disable-optimize . $topsrcdir/browser/config/mozconfig mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/objdir mk_add_options MOZ_MAKE_FLAGS="-s -j4" CC="gcc-4.2 -arch i386" CXX="g++-4.2 -arch i386" ac_add_options --with-macos-sdk=/Developer/SDKs/MacOSX10.5.sdk ac_add_options --target=i386-apple-darwin8.0.0 ac_add_options --enable-macos-target=10.5 ac_add_options --disable-crashreporter HOST_CC="gcc-4.2" HOST_CXX="g++-4.2" RANLIB=ranlib AR=ar AS=$CC LD=ld STRIP="strip -x -S" CROSS_COMPILE=1
Yes, after I worked around the assert in bug 575672 (which I did by changing the last number of the cubic-bezier on iq.js line 612 so it was no longer greater than 1), I got the assert for this bug. My .mozconfig was: . $topsrcdir/browser/config/mozconfig mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-ff-dbg mk_add_options MOZ_MAKE_FLAGS="-s -j4" ac_add_options --enable-debug ac_add_options --disable-optimize I'm on Mac (Snow Leopard) using a clean profile in Firefox.
> Yes, after I worked around the assert in bug 575672 (which I did by changing > the last number of the cubic-bezier on iq.js line 612 so it was no longer > greater than 1) OK, made that change and building now (on Leopard).
No assertion. Just to make sure, I'm using: mozilla% hg path default = http://hg.mozilla.org/users/edward.lee_engineering.uiuc.edu/tabcandy-central mozilla% hg parent changeset: 46704:da9dfdef8dfe user: Edward Lee <edilee@mozilla.com> date: Tue Jun 29 01:04:26 2010 -0700 summary: Bug 574188 - Include individual js pieces into tabcandy.js and expose content and skin files with jar.mn right?
No longer blocks: 574217
I've just run into this as well. In the Sync setup wizard we produce a page with the user's Sync Key. It can be either printed or saved. Both methods use a hidden iframe that loads the XHTML file. If the XHTML file contains <a> tags, I get the traceback below and a crash (Bus Error) on either print or save. If there are no links in the page, both work fine: ###!!! ABORT: aRelevantLinkVisited should only be set when we have a separate style: 'aRulesIfVisited || !aRelevantLinkVisited', file .../m-c/layout/style/nsStyleContext.cpp, line 179 nsStyleContext::FindChildWithRules(nsIAtom const*, nsRuleNode*, nsRuleNode*, int)+0x0000004B [.../m-c/obj-ff-dbg/dist/MinefieldDebug.app/Contents/MacOS/XUL +0x0050196B] nsStyleSet::GetContext(nsStyleContext*, nsRuleNode*, nsRuleNode*, int, int, nsIAtom*, nsCSSPseudoElements::Type)+0x0000010A [.../m-c/obj-ff-dbg/dist/MinefieldDebug.app/Contents/MacOS/XUL +0x0050854A] nsStyleSet::ResolveStyleFor(mozilla::dom::Element*, nsStyleContext*)+0x000001D4 [.../m-c/obj-ff-dbg/dist/MinefieldDebug.app/Contents/MacOS/XUL +0x00509928] nsFrameManager::ReResolveStyleContext(nsPresContext*, nsIFrame*, nsIContent*, nsStyleChangeList*, nsChangeHint, nsRestyleHint, int, mozilla::css::RestyleTracker&)+0x000006D8 [.../m-c/obj-ff-dbg/dist/MinefieldDebug.app/Contents/MacOS/XUL +0x003019DC] nsFrameManager::ComputeStyleChangeFor(nsIFrame*, nsStyleChangeList*, nsChangeHint, mozilla::css::RestyleTracker&, int)+0x0000011B [.../m-c/obj-ff-dbg/dist/MinefieldDebug.app/Contents/MacOS/XUL +0x00302809] nsCSSFrameConstructor::RestyleElement(mozilla::dom::Element*, nsIFrame*, nsChangeHint, mozilla::css::RestyleTracker&, int)+0x00000177 [.../m-c/obj-ff-dbg/dist/MinefieldDebug.app/Contents/MacOS/XUL +0x002BD855] mozilla::css::RestyleTracker::ProcessOneRestyle(mozilla::dom::Element*, nsRestyleHint, nsChangeHint)+0x0000013A [.../m-c/obj-ff-dbg/dist/MinefieldDebug.app/Contents/MacOS/XUL +0x002A4188] mozilla::css::RestyleTracker::ProcessRestyles()+0x00000425 [.../m-c/obj-ff-dbg/dist/MinefieldDebug.app/Contents/MacOS/XUL +0x002A2C5D] nsCSSFrameConstructor::ProcessPendingRestyles()+0x00000100 [.../m-c/obj-ff-dbg/dist/MinefieldDebug.app/Contents/MacOS/XUL +0x002BD612] PresShell::FlushPendingNotifications(mozFlushType)+0x0000027D [.../m-c/obj-ff-dbg/dist/MinefieldDebug.app/Contents/MacOS/XUL +0x0033E0D9] nsGfxScrollFrameInner::AsyncScrollPortEvent::Run()+0x0000003F [.../m-c/obj-ff-dbg/dist/MinefieldDebug.app/Contents/MacOS/XUL +0x003ACEB5] nsThread::ProcessNextEvent(int, int*)+0x000002A4 [.../m-c/obj-ff-dbg/dist/MinefieldDebug.app/Contents/MacOS/XUL +0x0164109A] NS_ProcessPendingEvents_P(nsIThread*, unsigned int)+0x00000092 [.../m-c/obj-ff-dbg/dist/MinefieldDebug.app/Contents/MacOS/XUL +0x015C80AF] nsBaseAppShell::NativeEventCallback()+0x000000B5 [.../m-c/obj-ff-dbg/dist/MinefieldDebug.app/Contents/MacOS/XUL +0x013911AF] nsAppShell::ProcessGeckoEvents(void*)+0x000001F1 [.../m-c/obj-ff-dbg/dist/MinefieldDebug.app/Contents/MacOS/XUL +0x0134355F] __CFRunLoopDoSources0+0x000004B1 [/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation +0x0003EF91] __CFRunLoopRun+0x0000042F [/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation +0x0003CBBF] CFRunLoopRunSpecific+0x000001C4 [/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation +0x0003C094] CFRunLoopRunInMode+0x00000061 [/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation +0x0003BEC1] RunCurrentEventLoopInMode+0x00000188 [/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox +0x00034F9C] ReceiveNextEventCommon+0x0000009E [/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox +0x00034C8D] BlockUntilNextEventMatchingListInMode+0x00000051 [/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox +0x00034BD6] _DPSNextEvent+0x0000034F [/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit +0x00048A89] -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]+0x0000009C [/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit +0x000482CA] -[NSApplication _realDoModalLoop:peek:]+0x000002D0 [/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit +0x002BF979] -[NSApplication runModalForWindow:]+0x00000111 [/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit +0x002BF0F5] -[NSPrintPanel runModalWithPrintInfo:]+0x0000024A [/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit +0x00514CFA] -[NSPrintPanel runModal]+0x00000050 [/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit +0x00514329] nsPrintDialogServiceX::Show(nsIDOMWindow*, nsIPrintSettings*, nsIWebBrowserPrint*)+0x00000391 [.../m-c/obj-ff-dbg/dist/MinefieldDebug.app/Contents/MacOS/XUL +0x0138662D] nsPrintingPromptService::ShowPrintDialog(nsIDOMWindow*, nsIWebBrowserPrint*, nsIPrintSettings*)+0x00000122 [.../m-c/obj-ff-dbg/dist/MinefieldDebug.app/Contents/MacOS/XUL +0x0104FD54] nsPrintEngine::DoCommonPrint(int, nsIPrintSettings*, nsIWebProgressListener*, nsIDOMDocument*)+0x00000D20 [.../m-c/obj-ff-dbg/dist/MinefieldDebug.app/Contents/MacOS/XUL +0x00BDAD9E] nsPrintEngine::CommonPrint(int, nsIPrintSettings*, nsIWebProgressListener*, nsIDOMDocument*)+0x0000002D [.../m-c/obj-ff-dbg/dist/MinefieldDebug.app/Contents/MacOS/XUL +0x00BDB6FF] nsPrintEngine::Print(nsIPrintSettings*, nsIWebProgressListener*)+0x0000008A [.../m-c/obj-ff-dbg/dist/MinefieldDebug.app/Contents/MacOS/XUL +0x00BDBA7A] DocumentViewerImpl::Print(nsIPrintSettings*, nsIWebProgressListener*)+0x0000053B [.../m-c/obj-ff-dbg/dist/MinefieldDebug.app/Contents/MacOS/XUL +0x002F990F] DocumentViewerImpl::LoadComplete(unsigned int)+0x00000470 [.../m-c/obj-ff-dbg/dist/MinefieldDebug.app/Contents/MacOS/XUL +0x002F5AAC] nsDocShell::EndPageLoad(nsIWebProgress*, nsIChannel*, unsigned int)+0x000001E7 [.../m-c/obj-ff-dbg/dist/MinefieldDebug.app/Contents/MacOS/XUL +0x00FBC9EB] nsDocShell::OnStateChange(nsIWebProgress*, nsIRequest*, unsigned int, unsigned int)+0x0000072D [.../m-c/obj-ff-dbg/dist/MinefieldDebug.app/Contents/MacOS/XUL +0x00FC3A09] nsDocLoader::FireOnStateChange(nsIWebProgress*, nsIRequest*, int, unsigned int)+0x00000260 [.../m-c/obj-ff-dbg/dist/MinefieldDebug.app/Contents/MacOS/XUL +0x00FE7062] nsDocLoader::doStopDocumentLoad(nsIRequest*, unsigned int)+0x000000B0 [.../m-c/obj-ff-dbg/dist/MinefieldDebug.app/Contents/MacOS/XUL +0x00FE78B0] nsDocLoader::DocLoaderIsEmpty(int)+0x0000037C [.../m-c/obj-ff-dbg/dist/MinefieldDebug.app/Contents/MacOS/XUL +0x00FE7C80] nsDocLoader::OnStopRequest(nsIRequest*, nsISupports*, unsigned int)+0x000004E4 [.../m-c/obj-ff-dbg/dist/MinefieldDebug.app/Contents/MacOS/XUL +0x00FE8F6A] nsLoadGroup::RemoveRequest(nsIRequest*, nsISupports*, unsigned int)+0x0000033E [.../m-c/obj-ff-dbg/dist/MinefieldDebug.app/Contents/MacOS/XUL +0x0007343A] nsDocument::DoUnblockOnload()+0x00000161 [.../m-c/obj-ff-dbg/dist/MinefieldDebug.app/Contents/MacOS/XUL +0x00623AA9] nsDocument::UnblockOnload(int)+0x0000011E [.../m-c/obj-ff-dbg/dist/MinefieldDebug.app/Contents/MacOS/XUL +0x00623BDA] nsDocument::DispatchContentLoadedEvents()+0x000004C3 [.../m-c/obj-ff-dbg/dist/MinefieldDebug.app/Contents/MacOS/XUL +0x00610F6B] nsRunnableMethodImpl<void (nsDocument::*)(), true>::Run()+0x00000065 [.../m-c/obj-ff-dbg/dist/MinefieldDebug.app/Contents/MacOS/XUL +0x0062A159] nsThread::ProcessNextEvent(int, int*)+0x000002A4 [.../m-c/obj-ff-dbg/dist/MinefieldDebug.app/Contents/MacOS/XUL +0x0164109A] NS_ProcessPendingEvents_P(nsIThread*, unsigned int)+0x00000092 [.../m-c/obj-ff-dbg/dist/MinefieldDebug.app/Contents/MacOS/XUL +0x015C80AF] nsBaseAppShell::NativeEventCallback()+0x000000B5 [.../m-c/obj-ff-dbg/dist/MinefieldDebug.app/Contents/MacOS/XUL +0x013911AF] nsAppShell::ProcessGeckoEvents(void*)+0x000001F1 [.../m-c/obj-ff-dbg/dist/MinefieldDebug.app/Contents/MacOS/XUL +0x0134355F] __CFRunLoopDoSources0+0x0000061B [/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation +0x0003F0FB] __CFRunLoopRun+0x0000042F [/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation +0x0003CBBF] CFRunLoopRunSpecific+0x000001C4 [/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation +0x0003C094] CFRunLoopRunInMode+0x00000061 [/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation +0x0003BEC1] RunCurrentEventLoopInMode+0x00000188 [/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox +0x00034F9C] ReceiveNextEventCommon+0x00000162 [/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox +0x00034D51] BlockUntilNextEventMatchingListInMode+0x00000051 [/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox +0x00034BD6] _DPSNextEvent+0x0000034F [/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit +0x00048A89] -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]+0x0000009C [/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit +0x000482CA] -[NSApplication run]+0x00000335 [/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit +0x0000A55B] nsAppShell::Run()+0x00000123 [.../m-c/obj-ff-dbg/dist/MinefieldDebug.app/Contents/MacOS/XUL +0x013422B1] nsAppStartup::Run()+0x00000094 [.../m-c/obj-ff-dbg/dist/MinefieldDebug.app/Contents/MacOS/XUL +0x01094D9E] XRE_main+0x00002D86 [.../m-c/obj-ff-dbg/dist/MinefieldDebug.app/Contents/MacOS/XUL +0x0002AE77] main+0x000002CA [.../m-c/obj-ff-dbg/dist/MinefieldDebug.app/Contents/MacOS/firefox-bin +0x000015F1] start+0x00000036 [.../m-c/obj-ff-dbg/dist/MinefieldDebug.app/Contents/MacOS/firefox-bin +0x00001272] ###!!! ABORT: aRelevantLinkVisited should only be set when we have a separate style: 'aRulesIfVisited || !aRelevantLinkVisited', file .../m-c/layout/style/nsStyleContext.cpp, line 179 Bus error
Some additional info: * this is an OSX debug build * the same technique doesn't crash Firefox 3.6.9 where we use it in the Firefox Sync add-on.
To reproduce: Apply "artifact" patch from bug 596566, and start to set up a new account in the Sync setup wizard. On the page that shows the passphrase, select either "Print..." or "Save..."
Mardak just confirmed via IRC that TabCandy too was producing this assertion because of an HTML link within a XUL iframe. I'm changing the title accordingly. I've done a bit more poking around on this and it's pretty easy to reproduce: 1. Put this somewhere in a XUL document (e.g. a dialog): <iframe src="chrome://browser/content/foobar.xhtml"/> 2. Create foobar.xhtml with some <a href="someURL"> links in it. (This is essentially what Sync does in bug 596566). If I remove the <a href=""> links from the XHTML page, there's no assertion and no crash. Leaving them like <a> works fine. Note that the OS X and Win32 opt builds aren't crashing. Here's a try build of my patches from bug 596566: http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/pweitershausen@mozilla.com-1460b6d25479/
Blocks: 596566
blocking2.0: --- → ?
Summary: FindChildWithRules aRelevantLinkVisited assertion when loading tabcandy page → FindChildWithRules aRelevantLinkVisited assertion when loading HTML page with links in XUL iframe
This doesn't *look* like a blocker to me: it can't be exploited by web content (any more), and it can either be worked around or is just an unpleasant assertion within chrome code.
blocking2.0: ? → -
> To reproduce: Apply "artifact" patch from bug 596566, and start to set up a new > account in the Sync setup wizard. On the page that shows the passphrase, select > either "Print..." or "Save..." I just did that. No assertion in a current trunk debug build (on Mac). Pretty sure I applied the "artifact" patch correctly.
Now how do I delete the sync account that was created in the process from the sync server?
(In reply to comment #22) > No assertion in a current trunk debug build (on Mac). Pretty > sure I applied the "artifact" patch correctly. That's... weird! Does the debug try build (see comment 20) also not assert and crash for you? (In reply to comment #23) > Now how do I delete the sync account that was created in the process from the > sync server? If you feel obliged you can close it at https://services.mozilla.com/delete-account/. Note that this webpage hasn't been updated to understand email based accounts yet. See the services.sync.username pref for the username that's been generated out of the email address you signed up with.
> Does the debug try build (see comment 20) also not assert and crash for you? That's correct, using the 32-bit mac debug build. No assert, no crash, nothing. > If you feel obliged I do, yeah. Might need to create another account with that username again as I test, no?
(In reply to comment #25) > > Does the debug try build (see comment 20) also not assert and crash for you? > > That's correct, using the 32-bit mac debug build. No assert, no crash, > nothing. Wow, weird. I wonder how my machine is special... FWIW I'm on 10.6.4. I will try with another OS X machine, though that's 10.6.4 as well... > > If you feel obliged > > I do, yeah. Might need to create another account with that username again as I > test, no? I don't see why would. Note that you don't really have to complete the setup wizard. You can just cancel after trying out the Save... or Print... option. That way the account never gets created in the first place.
(In reply to comment #25) > > Does the debug try build (see comment 20) also not assert and crash for you? > > That's correct, using the 32-bit mac debug build. No assert, no crash, > nothing. Hang on, the assert is related to visited links. Can you try again but before that go to one of the pages linked from the document, e.g. https://services.mozilla.com. I couldn't reproduce it just now on a clean profile either. But as soon as I visited that page, I got the crash again.
I'm on 10.6.4 as well. Trying steps from comment 27 now.
Ah, now I see it.
Oh, of course. This is a chrome document, so there are no :visited rules in any of the stylesheets. The style set assumes there's at least one :visited rule aroud somewhere; if there is not the asserts will fail (and they're NS_ABORT_IF_FALSE, so look like a crash in a debug build). We need to either weaken the asserts or add :visited rules to chrome.
Oh, PresShell::SetPreferenceStyleRules returns early for chrome docs. I think I looked for that once and missed it.
Thanks for digging into this! Adding an a:visited rule to the page fixes the assertion and crash (lolduh). The document will have to be properly styled anyway, so while the contents of the a:visited rule I added now will be temporary, its presence most probably won't.
No longer blocks: 585689
David, how would you feel about adding an empty :visited rule in the chrome case or something?
I need to figure out whether anything actually depends on what the assertions were asserting; it would make more sense to remove/weaken them if possible.
Blocks: 618792
I just came up against this in the DevTools repo. It is easy to reproduce in the latest nightly by creating an html link in an iframe in a chrome document when running a debug build. The workaround is to add a :visited rule to the css.
Some other STR (100%) if anyone interested: - Win7 - m-c debug build, c12172ae966d - clean profile - open www.pre-school.org.uk
> Some other STR (100%) if anyone interested: Unless that page is using XUL, that's a different bug. I'll look into it.
(In reply to comment #37) > > Some other STR (100%) if anyone interested: > > Unless that page is using XUL, that's a different bug. I'll look into it. No, it is a common web content page. Please CC me to that new bug.
I filed bug 690096 on another instance of this same abort (involving links in SVG-as-an-image).
Blocks: 690096
> - open www.pre-school.org.uk I can't seem to reproduce there. :(
(In reply to Boris Zbarsky (:bz) from comment #40) > > - open www.pre-school.org.uk > > I can't seem to reproduce there. :( I think I have a way to reproduce: change mozilla-central build UA to Aurora UA (9.0) and then load that site. This assertion popped on my today several times.
Ah, yes. Gotta love browser sniffing.... On that site, we're looking at an SVG image or resource document, so that's bug 690096.
I've run into this twice now. I think it's going to be a common thing for devtools.
Blocks: 709748
Blocks: 716529
No longer blocks: 709748
OK, so as far as comment 34 goes: As far as I can tell, nothing in FindChildWithRules itself depends on what this assertion is asserting. The only caller of FindChildWithRules is nsStyleSet::GetContext. I _think_ it doesn't depend on it either. So I think it's safe to remove the assertion....
Yes, agreed, I think we should removed the assertion (I also checked that nsStyleContext::GetVisitedDependentColor doesn't depend on it). We should also mark the other bugs on this dupes of this one.
Assignee: nobody → dbaron
Status: NEW → ASSIGNED
No longer blocks: 690096
Comment on attachment 8488893 [details] [diff] [review] Remove assertion about aRelevantLinkVisited that isn't needed, and assumes that all link elements are styled with a style sheet that has :visited rules r=me
Attachment #8488893 - Flags: review?(bzbarsky) → review+
Blocks: 1020244
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla35
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: