Summary: | HTML5 Parser: Fix fast/profiler tests that depend on event handler line numbers | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Tony Gentilcore <tonyg> | ||||
Component: | New Bugs | Assignee: | Tony Gentilcore <tonyg> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | abarth, eric | ||||
Priority: | P2 | ||||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | Other | ||||||
OS: | OS X 10.5 | ||||||
Bug Depends on: | |||||||
Bug Blocks: | 39259 | ||||||
Attachments: |
|
Description
Tony Gentilcore
2010-06-09 16:09:56 PDT
Created attachment 58306 [details]
Patch
Comment on attachment 58306 [details]
Patch
WebCore/html/HTML5Tokenizer.cpp:105
+ if (scriptController)
I'm worried that constructTreeFromToken can cause script to run synchronously, which could invalidate the |frame|, which would invalidate scriptController. Maybe we need a private helper function to get the script controller?
if (ScriptController* scriptController = script())
scriptController->setEventHandlerLineNumber(...)
I'm going to spoil you, but I'm going to merge your patch to TOT. :) Committed r60940: <http://trac.webkit.org/changeset/60940> Woh. Wasn't this a huge slowdown on the benchmark? We're adding two branches and a virtual function call to the per-token loop, no? Why do we need to reset the line number to 0 after each token is processed? (In reply to comment #3) > I'm going to spoil you, but I'm going to merge your patch to TOT. :) Thanks! Man you're fast. I had the same patch ready but it didn't finish building before the get together last night. There was one more place in Tokenizer that the script() fn could be used. I'll mail a patch for that. (In reply to comment #6) > Why do we need to reset the line number to 0 after each token is processed? I haven't confirmed, but I'm nearly certain that is for the case when a script dynamically adds an element with an event handler (it shouldn't be associated w/ the line number of the parser). In any case, it seemed safest to match the old Tokenizer's behavior for now. (In reply to comment #5) > Woh. Wasn't this a huge slowdown on the benchmark? We're adding two branches and a virtual function call to the per-token loop, no? Can you point me to the benchmark to run? > Can you point me to the benchmark to run? http://trac.webkit.org/browser/trunk/WebCore/benchmarks/parser/html-parser.html (In reply to comment #8) > (In reply to comment #6) > > Why do we need to reset the line number to 0 after each token is processed? > > I haven't confirmed, but I'm nearly certain that is for the case when a script dynamically adds an element with an event handler (it shouldn't be associated w/ the line number of the parser). In any case, it seemed safest to match the old Tokenizer's behavior for now. Some elements carry a createdByParser flag. But I guess not all. Otherwise that would be easy to check after the fact. |