RESOLVED DUPLICATE of bug 34421 Bug 28452
Web Inspector freezes on expanding large/complex DOM trees
https://bugs.webkit.org/show_bug.cgi?id=28452
Summary Web Inspector freezes on expanding large/complex DOM trees
Anthony Ricaud
Reported 2009-08-19 06:09:23 PDT
The linked page has a lot of nodes. When you open the inspector, it freezes while trying to render the DOM tree in the Elements panel. Obviously it shouldn't. We should at least be able to use the other panels.
Attachments
[PATCH] Optimize Position::isCandidate() and PositionIterator::isCandidate() (39.71 KB, patch)
2010-03-09 08:27 PST, Alexander Pavlov (apavlov)
pfeldman: review-
[PATCH] Style + nits fixed (40.63 KB, patch)
2010-03-09 09:11 PST, Alexander Pavlov (apavlov)
no flags
Timothy Hatcher
Comment 1 2009-08-19 09:27:54 PDT
This works fine in Safari 4, so it might be related to the DOM agent changes.
Timothy Hatcher
Comment 2 2009-08-19 09:30:11 PDT
It is still slow in Safari 4 when expanding the SVG <a xlink=""> element. But TOT really does hang for a long time.
Anthony Ricaud
Comment 3 2009-10-29 17:02:32 PDT
The inspector is now reactive when opening. But it is still hanging on expanding <a xlink>. Reflecting that in the title.
Pavel Feldman
Comment 4 2009-10-29 17:20:14 PDT
(In reply to comment #3) > The inspector is now reactive when opening. > > But it is still hanging on expanding <a xlink>. Reflecting that in the title. We should make dom agent return limited number of children (500?) and the total number of those. That way we would be able to render the 'Load 457 more nodes' link. It is not trivial though due to the node event listeners. Will need additional checks in the agent.
Alexander Pavlov (apavlov)
Comment 5 2010-02-10 06:04:59 PST
https://bugs.webkit.org/show_bug.cgi?id=34421 is the first stab at the issue. We can elaborate further if that solution is not sufficient.
Alexander Pavlov (apavlov)
Comment 6 2010-03-09 08:27:56 PST
Created attachment 50311 [details] [PATCH] Optimize Position::isCandidate() and PositionIterator::isCandidate()
WebKit Review Bot
Comment 7 2010-03-09 08:31:23 PST
Attachment 50311 [details] did not pass style-queue: Failed to run "WebKitTools/Scripts/check-webkit-style" exit_code: 1 WebCore/editing/htmlediting.cpp:76: Boolean expressions that span multiple lines should have their operators on the left side of the line instead of the right side. [whitespace/operators] [4] WebCore/dom/Position.cpp:740: Tests for true/false, null/non-null, and zero/non-zero should all be done without equality comparisons. [readability/comparison_to_zero] [5] WebCore/dom/Position.cpp:897: Boolean expressions that span multiple lines should have their operators on the left side of the line instead of the right side. [whitespace/operators] [4] WebCore/dom/Position.cpp:902: Boolean expressions that span multiple lines should have their operators on the left side of the line instead of the right side. [whitespace/operators] [4] Total errors found: 4 in 5 files If any of these errors are false positives, please file a bug against check-webkit-style.
Pavel Feldman
Comment 8 2010-03-09 08:32:47 PST
Comment on attachment 50311 [details] [PATCH] Optimize Position::isCandidate() and PositionIterator::isCandidate() > + bool isParentUserSelect = !nodeIsUserSelectNone(node()->parent()); > if (renderer->isBR()) > - return m_offset == 0 && !nodeIsUserSelectNone(node()->parent()); > + return m_offset == 0 && isParentUserSelect; I think you are regressing the general case here without any wins. Same below.
Alexander Pavlov (apavlov)
Comment 9 2010-03-09 09:11:28 PST
Created attachment 50314 [details] [PATCH] Style + nits fixed
WebKit Review Bot
Comment 10 2010-03-09 09:13:32 PST
Attachment 50314 [details] did not pass style-queue: Failed to run "WebKitTools/Scripts/check-webkit-style" exit_code: 1 WebCore/dom/Position.cpp:896: Tests for true/false, null/non-null, and zero/non-zero should all be done without equality comparisons. [readability/comparison_to_zero] [5] WebCore/dom/Position.cpp:901: Tests for true/false, null/non-null, and zero/non-zero should all be done without equality comparisons. [readability/comparison_to_zero] [5] Total errors found: 2 in 5 files If any of these errors are false positives, please file a bug against check-webkit-style.
Alexander Pavlov (apavlov)
Comment 11 2010-03-09 09:34:49 PST
This issue was fixed in 34421, so closing this bug as duplicate and filing another one to upstream http://code.google.com/p/chromium/issues/detail?id=31832 *** This bug has been marked as a duplicate of bug 34421 ***
Note You need to log in before you can comment on or make changes to this bug.