WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
55201
[Web Timing] loadEvent timing should refer to first load event if there are many
https://bugs.webkit.org/show_bug.cgi?id=55201
Summary
[Web Timing] loadEvent timing should refer to first load event if there are many
James Simonsen
Reported
2011-02-24 18:24:27 PST
[Web Timing] loadEvent timing should refer to first load event if there are many
Attachments
Patch
(3.85 KB, patch)
2011-02-24 18:26 PST
,
James Simonsen
no flags
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
James Simonsen
Comment 1
2011-02-24 18:26:12 PST
Created
attachment 83758
[details]
Patch
James Simonsen
Comment 2
2011-02-24 18:30:29 PST
This fixes the test we uploaded to the W3C.
Tony Gentilcore
Comment 3
2011-02-24 18:36:12 PST
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?
James Simonsen
Comment 4
2011-02-24 21:09:15 PST
(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.
WebKit Commit Bot
Comment 5
2011-02-26 04:05:11 PST
Comment on
attachment 83758
[details]
Patch Clearing flags on attachment: 83758 Committed
r79776
: <
http://trac.webkit.org/changeset/79776
>
WebKit Commit Bot
Comment 6
2011-02-26 04:05:16 PST
All reviewed patches have been landed. Closing bug.
Ryosuke Niwa
Comment 7
2011-02-26 05:46:27 PST
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
James Simonsen
Comment 8
2011-02-28 11:29:19 PST
(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.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug