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)
Tracking
()
RESOLVED
FIXED
mozilla35
Tracking | Status | |
---|---|---|
blocking2.0 | --- | - |
People
(Reporter: Mardak, Assigned: dbaron)
References
Details
Attachments
(2 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
bzbarsky
:
review+
|
Details | Diff | Splinter Review |
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
Comment 1•14 years ago
|
||
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.
Comment 2•14 years ago
|
||
So... this bug is missing some minor things like steps to reproduce. Care to add those? This assertion firing is pretty bad.
Reporter | ||
Comment 3•14 years ago
|
||
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
Comment 4•14 years ago
|
||
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).
Reporter | ||
Comment 5•14 years ago
|
||
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.
Reporter | ||
Comment 6•14 years ago
|
||
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.
Reporter | ||
Comment 7•14 years ago
|
||
Comment 8•14 years ago
|
||
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.
Comment 9•14 years ago
|
||
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.
Comment 10•14 years ago
|
||
Note that I _was_ getting the bug 575672 assert.
Comment 11•14 years ago
|
||
I followed the steps from comment 5. No assert (once I commented out the assert from bug 575672).
Comment 12•14 years ago
|
||
To be clear, I'm on Mac (Leopard) here; using a clean profile.
Reporter | ||
Comment 13•14 years ago
|
||
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
Comment 14•14 years ago
|
||
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.
Comment 15•14 years ago
|
||
> 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).
Comment 16•14 years ago
|
||
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?
Comment 17•14 years ago
|
||
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
Comment 18•14 years ago
|
||
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.
Comment 19•14 years ago
|
||
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..."
Comment 20•14 years ago
|
||
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
Comment 21•14 years ago
|
||
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: ? → -
Comment 22•14 years ago
|
||
> 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.
Comment 23•14 years ago
|
||
Now how do I delete the sync account that was created in the process from the sync server?
Comment 24•14 years ago
|
||
(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.
Comment 25•14 years ago
|
||
> 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?
Comment 26•14 years ago
|
||
(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.
Comment 27•14 years ago
|
||
(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.
Comment 28•14 years ago
|
||
I'm on 10.6.4 as well. Trying steps from comment 27 now.
Comment 29•14 years ago
|
||
Ah, now I see it.
Comment 30•14 years ago
|
||
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.
Assignee | ||
Comment 31•14 years ago
|
||
Oh, PresShell::SetPreferenceStyleRules returns early for chrome docs. I think I looked for that once and missed it.
Comment 32•14 years ago
|
||
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.
Comment 33•14 years ago
|
||
David, how would you feel about adding an empty :visited rule in the chrome case or something?
Assignee | ||
Comment 34•14 years ago
|
||
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.
Comment 35•13 years ago
|
||
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.
Comment 36•13 years ago
|
||
Some other STR (100%) if anyone interested:
- Win7
- m-c debug build, c12172ae966d
- clean profile
- open www.pre-school.org.uk
Comment 37•13 years ago
|
||
> Some other STR (100%) if anyone interested:
Unless that page is using XUL, that's a different bug. I'll look into it.
Comment 38•13 years ago
|
||
(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.
Comment 39•13 years ago
|
||
I filed bug 690096 on another instance of this same abort (involving links in SVG-as-an-image).
Comment 40•13 years ago
|
||
> - open www.pre-school.org.uk
I can't seem to reproduce there. :(
Comment 41•13 years ago
|
||
(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.
Comment 42•13 years ago
|
||
Ah, yes. Gotta love browser sniffing....
On that site, we're looking at an SVG image or resource document, so that's bug 690096.
Comment 43•13 years ago
|
||
I've run into this twice now. I think it's going to be a common thing for devtools.
Blocks: 709748
Updated•13 years ago
|
Comment 44•13 years ago
|
||
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....
Assignee | ||
Comment 45•10 years ago
|
||
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 | ||
Comment 46•10 years ago
|
||
Attachment #8488893 -
Flags: review?(bzbarsky)
Assignee | ||
Updated•10 years ago
|
Assignee: nobody → dbaron
Status: NEW → ASSIGNED
Comment 48•10 years ago
|
||
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+
Assignee | ||
Comment 49•10 years ago
|
||
Assignee | ||
Comment 50•10 years ago
|
||
Comment 53•10 years ago
|
||
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.
Description
•