Bug 153002
Summary: | Form submit event has a long delay before triggering when many controls on the page | ||
---|---|---|---|
Product: | WebKit | Reporter: | Jamie Gaskins <jgaskins+webkit> |
Component: | Forms | Assignee: | Nobody <webkit-unassigned> |
Status: | NEW | ||
Severity: | Normal | CC: | cdumez, rniwa, webkit-bug-importer |
Priority: | P2 | Keywords: | InRadar |
Version: | WebKit Nightly Build | ||
Hardware: | Mac | ||
OS: | OS X 10.11 |
Jamie Gaskins
A form's submit handler takes a long time to trigger when there are a lot of inputs on the page, even when they are not contained within that form.
Here is an example: http://jsbin.com/hasulikiqe/2/edit?html,js,console,output
It's a dummy todo-list app. With the JavaScript console open, you can see that it a second or so to trigger the submit handler (which just prints a message to the console) after entering text into the input field and pressing enter, even though none of the checkboxes are part of that form.
When we remove the checkboxes, the delay is gone: http://jsbin.com/rogipubexe/2/edit?html,js,console,output
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
Chris Dumez
I can reproduce with tip of tree. I see most of the CPU time spent in client code (injected bundle) under:
Running Time Self (ms) Symbol Name
994.0ms 24.5% 0.0 WebKit::InjectedBundlePageFormClient::willSendSubmitEvent(WebKit::WebPage*, WebCore::HTMLFormElement*, WebKit::WebFrame*, WebKit::WebFrame*, WTF::Vector<std::__1::pair<WTF::String, WTF::String>, 0ul, WTF::CrashOnOverflow, 16ul> const&)
Ryosuke Niwa
Maybe we're doing the work inside Safari autofill code?
Chris Dumez
(In reply to comment #2)
> Maybe we're doing the work inside Safari autofill code?
Yes, I was trying to get radar-importer to create a radar for me so I could post the profile and investigation results.
Chris Dumez
rdar://problem/24154762