[Web Timing] loadEvent timing should refer to first load event if there are many
Created attachment 83758 [details] Patch
This fixes the test we uploaded to the W3C.
Comment on attachment 83758 [details] Patch This fix looks good. But I'm wondering if it is ever correct to fire multiple load events. If not, would it be better to fix that underlying bug instead of this?
(In reply to comment #3) > (From update of attachment 83758 [details]) > This fix looks good. But I'm wondering if it is ever correct to fire multiple load events. If not, would it be better to fix that underlying bug instead of this? From a quick reading of the spec, it looks like it is valid to fire load twice. Any time the parser reaches the end, it's supposed to fire load. document.open() is supposed to create a new parser, so it seems valid to hit load repeatedly.
Comment on attachment 83758 [details] Patch Clearing flags on attachment: 83758 Committed r79776: <http://trac.webkit.org/changeset/79776>
All reviewed patches have been landed. Closing bug.
It seems like this patch caused fast/spatial-navigation/snav-single-select-list.html to crash on GTK: http://build.webkit.org/results/GTK%20Linux%2064-bit%20Debug/r79776%20(19760)/results.html Stack trace: http://webkit-bots.igalia.com/amd64/svn_79778.core-when_1298727058-_-who_DumpRenderTree-_-why_11.trace.html Thread 1 (Thread 17949): #0 0x00007f9eca092f12 in WTF::RefPtr<WTF::StringImpl>::get (this=0x31) at ../../Source/JavaScriptCore/wtf/RefPtr.h:60 #1 0x00007f9eca09129c in WTF::String::impl (this=0x31) at ../../Source/JavaScriptCore/wtf/text/WTFString.h:126 #2 0x00007f9eca09138c in WTF::AtomicString::impl (this=0x31) at ../../Source/JavaScriptCore/wtf/text/AtomicString.h:61 #3 0x00007f9eca0913ab in WTF::operator== (a=..., b=...) at ../../Source/JavaScriptCore/wtf/text/AtomicString.h:132 #4 0x00007f9eca091e52 in WebCore::QualifiedName::matches (this=0x2a31878, other=...) at ../../Source/WebCore/dom/QualifiedName.h:75 #5 0x00007f9eca091ff9 in WebCore::Element::hasTagName (this=0x2a31810, tagName=...) at ../../Source/WebCore/dom/Element.h:191 #6 0x00007f9eca20aac8 in WebCore::AccessibilityListBoxOption::listBoxOptionParentNode (this=0x26a0900) at ../../Source/WebCore/accessibility/AccessibilityListBoxOption.cpp:192 #7 0x00007f9eca20a935 in WebCore::AccessibilityListBoxOption::parentObject (this=0x26a0900) at ../../Source/WebCore/accessibility/AccessibilityListBoxOption.cpp:162 #8 0x00007f9eca210bcd in WebCore::AccessibilityObject::documentFrameView (this=0x26a0900) at ../../Source/WebCore/accessibility/AccessibilityObject.cpp:735 #9 0x00007f9eca210b75 in WebCore::AccessibilityObject::document (this=0x26a0900) at ../../Source/WebCore/accessibility/AccessibilityObject.cpp:724 #10 0x00007f9eca094c5f in WebCore::notifyChildrenSelectionChange (object=0x2a205e0) at ../../Source/WebCore/accessibility/gtk/AXObjectCacheAtk.cpp:72 #11 0x00007f9eca094ee4 in WebCore::AXObjectCache::postPlatformNotification (this=0x2a37a00, coreObject=0x2a205e0, notification=WebCore::AXObjectCache::AXSelectedChildrenChanged) at ../../Source/WebCore/accessibility/gtk/AXObjectCacheAtk.cpp:112 #12 0x00007f9eca22d5a3 in WebCore::AXObjectCache::notificationPostTimerFired (this=0x2a37a00) at ../../Source/WebCore/accessibility/AXObjectCache.cpp:465 #13 0x00007f9eca23913a in WebCore::Timer<WebCore::AXObjectCache>::fired (this=0x2a37b70) at ../../Source/WebCore/platform/Timer.h:100 #14 0x00007f9eca8f278c in WebCore::ThreadTimers::sharedTimerFiredInternal (this=0xe2fda0) at ../../Source/WebCore/platform/ThreadTimers.cpp:112 #15 0x00007f9eca8f26c3 in WebCore::ThreadTimers::sharedTimerFired () at ../../Source/WebCore/platform/ThreadTimers.cpp:90 #16 0x00007f9eca0e380e in WebCore::timeout_cb () at ../../Source/WebCore/platform/gtk/SharedTimerGtk.cpp:49 #17 0x00007f9ec72fedbb in g_timeout_dispatch (source=0x2a3f060, callback=0xe0cda0, user_data=0x21) at /tmp/buildd/glib2.0-2.27.91/./glib/gmain.c:3877 #18 0x00007f9ec72fe362 in g_main_dispatch (context=0xd8b1e0) at /tmp/buildd/glib2.0-2.27.91/./glib/gmain.c:2440 #19 g_main_context_dispatch (context=0xd8b1e0) at /tmp/buildd/glib2.0-2.27.91/./glib/gmain.c:3013 #20 0x00007f9ec7302a28 in g_main_context_iterate (context=0xd8b1e0, block=<value optimized out>, dispatch=<value optimized out>, self=<value optimized out>) at /tmp/buildd/glib2.0-2.27.91/./glib/gmain.c:3091 #21 0x00007f9ec7302f35 in g_main_loop_run (loop=0x2a72df0) at /tmp/buildd/glib2.0-2.27.91/./glib/gmain.c:3299 #22 0x00007f9ec9237657 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #23 0x000000000041e1e9 in runTest (testPathOrURL=...) at ../../Tools/DumpRenderTree/gtk/DumpRenderTree.cpp:679 #24 0x000000000041d87b in runTestingServerLoop () at ../../Tools/DumpRenderTree/gtk/DumpRenderTree.cpp:489 #25 0x000000000041f960 in main (argc=2, argv=0x7fff7757f828) at ../../Tools/DumpRenderTree/gtk/DumpRenderTree.cpp:1143
(In reply to comment #7) > It seems like this patch caused fast/spatial-navigation/snav-single-select-list.html to crash on GTK: > http://build.webkit.org/results/GTK%20Linux%2064-bit%20Debug/r79776%20(19760)/results.html I don't see any of the changed code on the stack and it seems unrelated. I would suspect another change or just flakiness.