WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
55456
Web Inspector: Extremely slow DOM search in GMail
https://bugs.webkit.org/show_bug.cgi?id=55456
Summary
Web Inspector: Extremely slow DOM search in GMail
Alexander Pavlov (apavlov)
Reported
2011-03-01 04:08:20 PST
1. Open a message in gmail 2. Click inspect element somewhere 3. Search for '.oM' using the search box on top of the Web Inspector The search takes forever (almost). Upstreaming Chromium issue
http://code.google.com/p/chromium/issues/detail?id=64928
Attachments
[PATCH] Suggested solution
(7.39 KB, patch)
2011-03-01 05:17 PST
,
Alexander Pavlov (apavlov)
no flags
Details
Formatted Diff
Diff
[PATCH] Avoid storing refs to normalHTML in nodes not participating in search highlighting
(7.53 KB, patch)
2011-03-01 05:58 PST
,
Alexander Pavlov (apavlov)
yurys
: review+
Details
Formatted Diff
Diff
[PATCH] Comments addressed, please re-review
(10.79 KB, patch)
2011-03-01 08:01 PST
,
Alexander Pavlov (apavlov)
yurys
: review+
Details
Formatted Diff
Diff
Show Obsolete
(2)
View All
Add attachment
proposed patch, testcase, etc.
Alexander Pavlov (apavlov)
Comment 1
2011-03-01 05:17:22 PST
Created
attachment 84217
[details]
[PATCH] Suggested solution
Alexander Pavlov (apavlov)
Comment 2
2011-03-01 05:58:48 PST
Created
attachment 84220
[details]
[PATCH] Avoid storing refs to normalHTML in nodes not participating in search highlighting
Yury Semikhatsky
Comment 3
2011-03-01 06:16:40 PST
Comment on
attachment 84220
[details]
[PATCH] Avoid storing refs to normalHTML in nodes not participating in search highlighting View in context:
https://bugs.webkit.org/attachment.cgi?id=84220&action=review
> Source/WebCore/inspector/front-end/ElementsTreeOutline.js:1451 > text = text.substring(match.index + 1);
while (match) { 1449 highlightSearchResult(this.listItemElement, offset + match.index, match[0].length); Could we replace quadratic algorithm here with a linear one?
> Source/WebCore/inspector/front-end/utilities.js:1023 > +function setAtTextOffset(textNodeIterator, relativeOffset)
This should be a method on the iterator.
> Source/WebCore/inspector/front-end/utilities.js:1062 > + var textNodeIterator = new OrderedNodeSnapshotIterator(document.evaluate(".//text()", element, null, XPathResult.ORDERED_NODE_SNAPSHOT_TYPE, null));
Consider inlining the iterator. Looks like a loop would work equally well here.
Alexander Pavlov (apavlov)
Comment 4
2011-03-01 08:01:08 PST
Created
attachment 84231
[details]
[PATCH] Comments addressed, please re-review
Yury Semikhatsky
Comment 5
2011-03-01 08:13:01 PST
Comment on
attachment 84231
[details]
[PATCH] Comments addressed, please re-review View in context:
https://bugs.webkit.org/attachment.cgi?id=84231&action=review
> Source/WebCore/inspector/front-end/utilities.js:1034 > + var previousOffset = 0;
This is not used. Please remove.
Alexander Pavlov (apavlov)
Comment 6
2011-03-01 08:52:15 PST
Landed with the unused var fix. Committing to
http://svn.webkit.org/repository/webkit/trunk
... M Source/WebCore/ChangeLog M Source/WebCore/inspector/front-end/ElementsPanel.js M Source/WebCore/inspector/front-end/ElementsTreeOutline.js M Source/WebCore/inspector/front-end/utilities.js Committed
r80003
WebKit Review Bot
Comment 7
2011-03-01 09:42:51 PST
http://trac.webkit.org/changeset/80003
might have broken GTK Linux 64-bit Debug The following tests are not passing: loader/reload-subresource-when-type-changes.html
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