36037 2010-03-11 15:46:30 -0800 REGRESSION(51522): typing at the end of a line in designMode documents is *very* slow 2010-06-05 00:50:22 -0700 1 1 1 Unclassified WebKit HTML Editing 528+ (Nightly build) All All RESOLVED FIXED GoogleBug, InRadar, Regression P1 Normal --- 1 ojan webkit-unassigned abarth adele dglazkov enrica eric jamesr jaroslav.benc justin.garcia mitz webkit.review.bot oldest_to_newest 198815 0 ojan 2010-03-11 15:46:30 -0800 This affects the script editor in Google Spreadsheets (which uses http://marijn.haverbeke.nl/codemirror/). Test case attached. Typing a character at the end of the line takes seconds on my machine. The while loop in previousCandidate(const Position& position) in htmlediting.cpp seems to be where all the time is going. Not sure yet what exactly is going wrong. 198817 1 jamesr 2010-03-11 15:55:38 -0800 I think you forgot to attach the test case. 198819 2 50555 ojan 2010-03-11 16:00:41 -0800 Created attachment 50555 Test case I blame bugzilla! 198845 3 ojan 2010-03-11 16:50:25 -0800 I think the bug is in PositionIterator::isCandidate. Still not sure though. The call to endOfBlock is normally constant-time in the average case, but this is hitting the worst-case where it never finds a candidate, so it loops over every node in the body. The offending block looks to be: if (!m_anchorNode->hasTagName(htmlTag) && renderer->isBlockFlow()) { if (toRenderBlock(renderer)->height() || m_anchorNode->hasTagName(bodyTag)) { if (!Position::hasRenderedNonAnonymousDescendantsWithHeight(renderer)) return atStartOfNode() && !Position::nodeIsUserSelectNone(m_anchorNode); return m_anchorNode->isContentEditable() && !Position::nodeIsUserSelectNone(m_anchorNode) && Position(*this).atEditingBoundary(); } } The return statement at the end is wrong I think. This is the case where we're in the body element and it assumes that a position should only be in the body element if we're at an editing boundary (i.e. on the end of a node that's not editable). But this case where all the nodes are children of the body clearly should return true here and doesn't. Still not sure what the right fix is. 198849 4 ojan 2010-03-11 16:57:04 -0800 Actually, I take it back. I misread the code. The problem is definitely that endOfBlock is looping through each node in the body element, still not quite sure where the bug is though. 198854 5 ojan 2010-03-11 17:14:00 -0800 Looks this is a recent regression. http://trac.webkit.org/changeset/51522 198855 6 ojan 2010-03-11 17:17:06 -0800 I confirmed looking at nightlies that the bug doesn't happen at r51490 and does happen at r51559. 198884 7 ojan 2010-03-11 18:14:44 -0800 So, it turns out that without the extra early return added in r51522, we still loop over every node in the body element, but we do so much much faster. It's the call to Position(*this).atEditingBoundary() that takes almost all the time. Not sure what's so slow about it. Also, it really sucks that we loop over every node in the body element just to find the end of the block. Seems like that should be fixable. 199126 8 enrica 2010-03-12 10:34:16 -0800 (In reply to comment #7) > So, it turns out that without the extra early return added in r51522, we still > loop over every node in the body element, but we do so much much faster. It's > the call to Position(*this).atEditingBoundary() that takes almost all the time. > Not sure what's so slow about it. > > Also, it really sucks that we loop over every node in the body element just to > find the end of the block. Seems like that should be fixable. I changed the code to support a scenario that was not covered before. There is not much that can be done in that place if we want to be able to support sophisticated mix of editable and non editable elements and be able to place the caret in empty editable elements. The right fix is to avoid looping through every node. 216121 9 54101 ojan 2010-04-22 15:52:29 -0700 Created attachment 54101 Patch 216124 10 54101 ojan 2010-04-22 15:54:21 -0700 Comment on attachment 54101 Patch This is a speculative patch that eseidel and I wrote. It makes iterating over positions more correct. We were skipping many positions before. This does fix the hang, but it causes a number of layout tests to fail. I haven't had time to look into whether they are actual regressions and won't anytime soon. Posting this patch in the hopes that someone else can take it up. 230003 11 56949 enrica 2010-05-24 17:42:05 -0700 Created attachment 56949 Patch2 230010 12 enrica 2010-05-24 17:57:28 -0700 Radar bug <rdar://problem/8022887> 230016 13 56949 mitz 2010-05-24 18:06:55 -0700 Comment on attachment 56949 Patch2 Should you also patch the PositionIterator constructor for consistency so that whenever m_anchorNode has child nodes, m_offsetInAnchor is 0? 230330 14 56949 darin 2010-05-25 10:11:49 -0700 Comment on attachment 56949 Patch2 > + m_offsetInAnchor = (m_anchorNode->hasChildNodes())? 0: lastOffsetForEditing(m_anchorNode); Formatting nitpick: Please write it like this: m_offsetInAnchor = m_anchorNode->hasChildNodes() ? 0: lastOffsetForEditing(m_anchorNode); But also, it seems wasteful to call lastOffsetForEditing in a case where we already know the node is non-null and we know that hasChildNodes is false. The special editingIgnoresContent behavior is the main reason we have the lastOffsetForEditing function. If we're not trying to implement that rule, then I think the code above is equivalent to this: m_offsetInAnchor = m_anchorNode->offsetInCharacters() ? m_anchorNode->maxCharacterOffset() : 0; For efficiency we could optimize it like this: m_offsetInAnchor = (m_anchorNode->hasChildNodes() || !m_anchorNode->offsetInCharacters()) ? 0 : m_anchorNode->maxCharacterOffset(); I'm not sure which is the best way to write it, but I do think that calling lastOffsetForEditing is a little strange. On the other hand, using it consistently might be clearer from a code readability point of view. r=me even if you don't agree with my comments. It's OK to just fix the formatting nitpick. 230352 15 enrica 2010-05-25 10:57:47 -0700 (In reply to comment #13) > (From update of attachment 56949 [details]) > Should you also patch the PositionIterator constructor for consistency so that whenever m_anchorNode has child nodes, m_offsetInAnchor is 0? I tried that initially, but a lot of tests fail, some crashing too. 230365 16 enrica 2010-05-25 11:08:22 -0700 (In reply to comment #14) > (From update of attachment 56949 [details]) > > + m_offsetInAnchor = (m_anchorNode->hasChildNodes())? 0: lastOffsetForEditing(m_anchorNode); > > Formatting nitpick: Please write it like this: > > m_offsetInAnchor = m_anchorNode->hasChildNodes() ? 0: lastOffsetForEditing(m_anchorNode); > sure, I'll fix it. > But also, it seems wasteful to call lastOffsetForEditing in a case where we already know the node is non-null and we know that hasChildNodes is false. The special editingIgnoresContent behavior is the main reason we have the lastOffsetForEditing function. If we're not trying to implement that rule, then I think the code above is equivalent to this: > > m_offsetInAnchor = m_anchorNode->offsetInCharacters() ? m_anchorNode->maxCharacterOffset() : 0; > I agree that we don't need the test on the children, since we know already. but how can we be sure we don't need the editingIgnoresContent behavior? If you look at the code above this for the case where m_nodeAfterPositionInAnchor is not null, lastOffsetForEditing is used there too. I don't have any reason to believe we can ignore editingIgnoresContent. Could you please explain? I'll try what you're suggesting and see if it breaks any of the tests. > For efficiency we could optimize it like this: > > m_offsetInAnchor = (m_anchorNode->hasChildNodes() || !m_anchorNode->offsetInCharacters()) ? 0 : m_anchorNode->maxCharacterOffset(); > > I'm not sure which is the best way to write it, but I do think that calling lastOffsetForEditing is a little strange. On the other hand, using it consistently might be clearer from a code readability point of view. > > r=me even if you don't agree with my comments. It's OK to just fix the formatting nitpick. 230375 17 enrica 2010-05-25 11:21:53 -0700 Committed revision 60176. 230380 18 eric 2010-05-25 11:33:36 -0700 It seems there are more fixes in attachment 54101 which we should eventually make in PositionIterator. 230386 19 enrica 2010-05-25 11:45:27 -0700 (In reply to comment #18) > It seems there are more fixes in attachment 54101 [details] which we should eventually make in PositionIterator. I'm not sure I agree. That patch broke a number of tests and some crashed. The behavior of increment is correct, what was wrong was the behavior of decrement that was causing to iterate over the wrong positions. I don't think there is anything wrong with the intended behavior of PositionIterator, there was just a bug in the implementation. 230390 20 eric 2010-05-25 12:00:06 -0700 Perhaps we made a mistake when typing up attachment 54101 then. I am too far removed from context to really comment. 230393 21 ojan 2010-05-25 12:16:13 -0700 (In reply to comment #19) > (In reply to comment #18) > > It seems there are more fixes in attachment 54101 [details] [details] which we should eventually make in PositionIterator. > > I'm not sure I agree. That patch broke a number of tests and some crashed. The behavior of increment is correct, what was wrong was the behavior of decrement that was causing to iterate over the wrong positions. > I don't think there is anything wrong with the intended behavior of PositionIterator, there was just a bug in the implementation. PositionIterator should iterate over all possible Positions, right? I don't think increment does currently. It just doesn't happen to hit in this case. The code in attachment 54101 may well have been wrong, but I'm pretty sure the existing increment implementation skips over some positions. Unless you think I'm wrong, I think it deserves a FIXME. 230394 22 webkit.review.bot 2010-05-25 12:17:42 -0700 http://trac.webkit.org/changeset/60176 might have broken Tiger Intel Release 230398 23 enrica 2010-05-25 12:29:11 -0700 (In reply to comment #21) > (In reply to comment #19) > > (In reply to comment #18) > > > It seems there are more fixes in attachment 54101 [details] [details] [details] which we should eventually make in PositionIterator. > > > > I'm not sure I agree. That patch broke a number of tests and some crashed. The behavior of increment is correct, what was wrong was the behavior of decrement that was causing to iterate over the wrong positions. > > I don't think there is anything wrong with the intended behavior of PositionIterator, there was just a bug in the implementation. > > PositionIterator should iterate over all possible Positions, right? I don't think increment does currently. It just doesn't happen to hit in this case. The code in attachment 54101 [details] may well have been wrong, but I'm pretty sure the existing increment implementation skips over some positions. Unless you think I'm wrong, I think it deserves a FIXME. I'll be happy to look into this while this is still fresh in my mind. Do you have an example of a case where increment skips positions? Keep in mind that m_anchorNode and m_offsetInAnchor only represent the current iterator position. To get the real position we need to use the Position() operator. Moreover lastOffsetForEditing calls editingIgnoresContent internally to skip some positions on purpose. 234566 24 ap 2010-06-05 00:50:22 -0700 *** Bug 40165 has been marked as a duplicate of this bug. *** 50555 2010-03-11 16:00:41 -0800 2010-03-11 16:00:41 -0800 Test case scratch2.html text/html 153 ojan PHNjcmlwdD4KZm9yICh2YXIgaSA9IDA7IGkgPCAyMDAwOyBpKyspIHsKICAgIGRvY3VtZW50Lndy aXRlKCdUeXBpbmcgYXQgdGhlIGVuZCBvZiB0aGlzIGxpbmUgaXMgdmVyeSBzbG93Ljxicj4nKTsK fQpkb2N1bWVudC5kZXNpZ25Nb2RlID0gJ29uJzsKPC9zY3JpcHQ+ 54101 2010-04-22 15:52:29 -0700 2010-05-24 17:42:05 -0700 Patch bug-36037-20100422155228.patch text/plain 4424 ojan ZGlmZiAtLWdpdCBhL1dlYkNvcmUvZG9tL1Bvc2l0aW9uSXRlcmF0b3IuY3BwIGIvV2ViQ29yZS9k b20vUG9zaXRpb25JdGVyYXRvci5jcHAKaW5kZXggZjViNjVmNS4uODJjMTNmMCAxMDA2NDQKLS0t IGEvV2ViQ29yZS9kb20vUG9zaXRpb25JdGVyYXRvci5jcHAKKysrIGIvV2ViQ29yZS9kb20vUG9z aXRpb25JdGVyYXRvci5jcHAKQEAgLTUxLDE5ICs1MSwyNCBAQCB2b2lkIFBvc2l0aW9uSXRlcmF0 b3I6OmluY3JlbWVudCgpCiAgICAgICAgIHJldHVybjsKIAogICAgIGlmIChtX25vZGVBZnRlclBv c2l0aW9uSW5BbmNob3IpIHsKKyAgICAgICAgQVNTRVJUKCFtX29mZnNldEluQW5jaG9yKTsKICAg ICAgICAgbV9hbmNob3JOb2RlID0gbV9ub2RlQWZ0ZXJQb3NpdGlvbkluQW5jaG9yOwogICAgICAg ICBtX25vZGVBZnRlclBvc2l0aW9uSW5BbmNob3IgPSBtX2FuY2hvck5vZGUtPmZpcnN0Q2hpbGQo KTsKLSAgICAgICAgbV9vZmZzZXRJbkFuY2hvciA9IDA7CiAgICAgICAgIHJldHVybjsKICAgICB9 CiAKLSAgICBpZiAoIW1fYW5jaG9yTm9kZS0+aGFzQ2hpbGROb2RlcygpICYmIG1fb2Zmc2V0SW5B bmNob3IgPCBsYXN0T2Zmc2V0Rm9yRWRpdGluZyhtX2FuY2hvck5vZGUpKQorICAgIC8vIGtpZHMg JiYgbGFzdE9mZnNldCAtPiBwb3N0aW9uIGFmdGVyIGFuY2hvcgorICAgIC8vICFraWRzICYmIGxh c3RPZmZzZXQgLT4gcG9zaXRpb24gYWZ0ZXIgYW5jaG9yCisgICAgLy8ga2lkcyAmJiAhbGFzdE9m ZnNldCAtPiBBU1NFUlQhCisgICAgLy8gIWtpZHMgJiYgIWxhc3RPZmZzZXQgLT4gb2Zmc2V0KysK KworICAgIGlmIChtX29mZnNldEluQW5jaG9yIDwgbGFzdE9mZnNldEZvckVkaXRpbmcobV9hbmNo b3JOb2RlKSkgeworICAgICAgICBBU1NFUlQoIW1fYW5jaG9yTm9kZS0+aGFzQ2hpbGROb2Rlcygp KTsKICAgICAgICAgbV9vZmZzZXRJbkFuY2hvciA9IFBvc2l0aW9uOjp1bmNoZWNrZWROZXh0T2Zm c2V0KG1fYW5jaG9yTm9kZSwgbV9vZmZzZXRJbkFuY2hvcik7Ci0gICAgZWxzZSB7Ci0gICAgICAg IG1fbm9kZUFmdGVyUG9zaXRpb25JbkFuY2hvciA9IG1fYW5jaG9yTm9kZTsKLSAgICAgICAgbV9h bmNob3JOb2RlID0gbV9ub2RlQWZ0ZXJQb3NpdGlvbkluQW5jaG9yLT5wYXJlbnROb2RlKCk7Ci0g ICAgICAgIG1fbm9kZUFmdGVyUG9zaXRpb25JbkFuY2hvciA9IG1fbm9kZUFmdGVyUG9zaXRpb25J bkFuY2hvci0+bmV4dFNpYmxpbmcoKTsKLSAgICAgICAgbV9vZmZzZXRJbkFuY2hvciA9IDA7Cisg ICAgfSBlbHNlIHsKKyAgICAgICAgbV9ub2RlQWZ0ZXJQb3NpdGlvbkluQW5jaG9yID0gbV9hbmNo b3JOb2RlLT5uZXh0U2libGluZygpOworICAgICAgICBtX2FuY2hvck5vZGUgPSBtX2FuY2hvck5v ZGUtPnBhcmVudE5vZGUoKTsKKyAgICAgICAgbV9vZmZzZXRJbkFuY2hvciA9IG1fbm9kZUFmdGVy UG9zaXRpb25JbkFuY2hvciA/IDAgOiBsYXN0T2Zmc2V0Rm9yRWRpdGluZyhtX2FuY2hvck5vZGUp OwogICAgIH0KIH0KIApAQCAtNzMsNiArNzgsNyBAQCB2b2lkIFBvc2l0aW9uSXRlcmF0b3I6OmRl Y3JlbWVudCgpCiAgICAgICAgIHJldHVybjsKIAogICAgIGlmIChtX25vZGVBZnRlclBvc2l0aW9u SW5BbmNob3IpIHsKKyAgICAgICAgQVNTRVJUKCFtX29mZnNldEluQW5jaG9yKTsKICAgICAgICAg bV9hbmNob3JOb2RlID0gbV9ub2RlQWZ0ZXJQb3NpdGlvbkluQW5jaG9yLT5wcmV2aW91c1NpYmxp bmcoKTsKICAgICAgICAgaWYgKG1fYW5jaG9yTm9kZSkgewogICAgICAgICAgICAgbV9ub2RlQWZ0 ZXJQb3NpdGlvbkluQW5jaG9yID0gMDsKQEAgLTgwLDIyICs4NiwyNSBAQCB2b2lkIFBvc2l0aW9u SXRlcmF0b3I6OmRlY3JlbWVudCgpCiAgICAgICAgIH0gZWxzZSB7CiAgICAgICAgICAgICBtX25v ZGVBZnRlclBvc2l0aW9uSW5BbmNob3IgPSBtX25vZGVBZnRlclBvc2l0aW9uSW5BbmNob3ItPnBh cmVudE5vZGUoKTsKICAgICAgICAgICAgIG1fYW5jaG9yTm9kZSA9IG1fbm9kZUFmdGVyUG9zaXRp b25JbkFuY2hvci0+cGFyZW50Tm9kZSgpOwotICAgICAgICAgICAgbV9vZmZzZXRJbkFuY2hvciA9 IDA7CiAgICAgICAgIH0KICAgICAgICAgcmV0dXJuOwogICAgIH0KIAotICAgIGlmIChtX29mZnNl dEluQW5jaG9yKSB7Ci0gICAgICAgIG1fb2Zmc2V0SW5BbmNob3IgPSBQb3NpdGlvbjo6dW5jaGVj a2VkUHJldmlvdXNPZmZzZXQobV9hbmNob3JOb2RlLCBtX29mZnNldEluQW5jaG9yKTsKKyAgICAv LyBraWRzICYmIHplcm8gLT4gb2Zmc2V0IGJlZm9yZSBhbmNob3IKKyAgICAvLyAha2lkcyAmJiB6 ZXJvIC0+IG9mZnNldCBiZWZvcmUgYW5jaG9yCisgICAgLy8ga2lkcyAmJiBub24temVybyAtPiBt dXN0IGJlIGxhc3QsIGdvIGludG8gcHJldmlvdXMga2lkCisgICAgLy8gIWtpZHMgJiYgbm9uLXpl cm8gLT4ganVzdCBkZWNyZW1lbnQKKworICAgIGlmICghbV9vZmZzZXRJbkFuY2hvcikgeworICAg ICAgICBtX25vZGVBZnRlclBvc2l0aW9uSW5BbmNob3IgPSBtX2FuY2hvck5vZGU7CisgICAgICAg IG1fYW5jaG9yTm9kZSA9IG1fYW5jaG9yTm9kZS0+cGFyZW50Tm9kZSgpOwogICAgIH0gZWxzZSB7 CiAgICAgICAgIGlmIChtX2FuY2hvck5vZGUtPmhhc0NoaWxkTm9kZXMoKSkgeworICAgICAgICAg ICAgQVNTRVJUKG1fb2Zmc2V0SW5BbmNob3IgPT0gbGFzdE9mZnNldEZvckVkaXRpbmcobV9hbmNo b3JOb2RlKSk7CiAgICAgICAgICAgICBtX2FuY2hvck5vZGUgPSBtX2FuY2hvck5vZGUtPmxhc3RD aGlsZCgpOwotICAgICAgICAgICAgaWYgKCFtX2FuY2hvck5vZGUtPmhhc0NoaWxkTm9kZXMoKSkK LSAgICAgICAgICAgICAgICBtX29mZnNldEluQW5jaG9yID0gbGFzdE9mZnNldEZvckVkaXRpbmco bV9hbmNob3JOb2RlKTsKLSAgICAgICAgfSBlbHNlIHsKLSAgICAgICAgICAgIG1fbm9kZUFmdGVy UG9zaXRpb25JbkFuY2hvciA9IG1fYW5jaG9yTm9kZTsKLSAgICAgICAgICAgIG1fYW5jaG9yTm9k ZSA9IG1fYW5jaG9yTm9kZS0+cGFyZW50Tm9kZSgpOwotICAgICAgICB9CisgICAgICAgICAgICBt X29mZnNldEluQW5jaG9yID0gbGFzdE9mZnNldEZvckVkaXRpbmcobV9hbmNob3JOb2RlKTsKKyAg ICAgICAgfSBlbHNlCisgICAgICAgICAgICBtX29mZnNldEluQW5jaG9yID0gUG9zaXRpb246OnVu Y2hlY2tlZFByZXZpb3VzT2Zmc2V0KG1fYW5jaG9yTm9kZSwgbV9vZmZzZXRJbkFuY2hvcik7CiAg ICAgfQogfQogCmRpZmYgLS1naXQgYS9XZWJDb3JlL2RvbS9Qb3NpdGlvbkl0ZXJhdG9yLmggYi9X ZWJDb3JlL2RvbS9Qb3NpdGlvbkl0ZXJhdG9yLmgKaW5kZXggN2FmODk3Ny4uMjMzYTY0ZSAxMDA2 NDQKLS0tIGEvV2ViQ29yZS9kb20vUG9zaXRpb25JdGVyYXRvci5oCisrKyBiL1dlYkNvcmUvZG9t L1Bvc2l0aW9uSXRlcmF0b3IuaApAQCAtMzQsNiArMzQsNyBAQCBuYW1lc3BhY2UgV2ViQ29yZSB7 CiAvLyBBIFBvc2l0aW9uIGl0ZXJhdG9yIHdpdGggY29uc3RhbnQtdGltZQogLy8gaW5jcmVtZW50 LCBkZWNyZW1lbnQsIGFuZCBzZXZlcmFsIHByZWRpY2F0ZXMgb24gdGhlIFBvc2l0aW9uIGl0IGlz IGF0LgogLy8gQ29udmVyc2lvbiB0by9mcm9tIFBvc2l0aW9uIGlzIE8obikgaW4gdGhlIG9mZnNl dC4KKy8vIEl0IGlzIE5PVCBzYWZlIHRvIG11dGF0ZSB0aGUgRE9NIHdoaWxlIGl0ZXJhdGluZyB3 aXRoIGEgUG9zaXRpb25JdGVyYXRvci4KIGNsYXNzIFBvc2l0aW9uSXRlcmF0b3IgewogcHVibGlj OgogICAgIFBvc2l0aW9uSXRlcmF0b3IoKQpAQCAtNjUsOCArNjYsMTYgQEAgcHVibGljOgogCiBw cml2YXRlOgogICAgIE5vZGUqIG1fYW5jaG9yTm9kZTsKKyAgICAvLyBtX25vZGVBZnRlclBvc2l0 aW9uSW5BbmNob3IgaXMgMCB3aGVuOgorICAgIC8vIC0gbV9hbmNob3JOb2RlIGlzIDAgT1IKKyAg ICAvLyAtICFtX2FuY2hvck5vZGUtPmhhc0NoaWxkTm9kZXMoKSBPUgorICAgIC8vIC0gbV9vZmZz ZXRJbkFuY2hvciA9PSBsYXN0T2Zmc2V0Rm9yRWRpdGluZyhtX2FuY2hvck5vZGUpCiAgICAgTm9k ZSogbV9ub2RlQWZ0ZXJQb3NpdGlvbkluQW5jaG9yOyAvLyBJZiB0aGlzIGlzIG5vbi1udWxsLCBt X25vZGVBZnRlclBvc2l0aW9uSW5BbmNob3ItPnBhcmVudE5vZGUoKSA9PSBtX2FuY2hvck5vZGU7 CisgICAgLy8gbV9vZmZzZXRJbkFuY2hvciBpcyAwIHdoZW46CisgICAgLy8gLSBtX25vZGVBZnRl clBvc2l0aW9uSW5BbmNob3IgaXMgbm9uLXplcm8gT1IKKyAgICAvLyAtIFBvc2l0aW9uIGlzIGZp cnN0IHBvc2l0aW9uIG9mIHRoZSBhbmNob3IgYW5kICFtX2FuY2hvck5vZGUtPmhhc0NoaWxkTm9k ZXMoKQogICAgIGludCBtX29mZnNldEluQW5jaG9yOworICAgIC8vIFRoaXMgYWx3YXlzIGhvbGRz OiBBU1NFUlQoIShtX25vZGVBZnRlclBvc2l0aW9uSW5BbmNob3IgJiYgbV9vZmZzZXRJbkFuY2hv cikpOwogfTsKIAogfSAvLyBuYW1lc3BhY2UgV2ViQ29yZQo= 56949 2010-05-24 17:42:05 -0700 2010-05-25 10:11:48 -0700 Patch2 bug8022887.txt text/plain 2677 enrica SW5kZXg6IFdlYkNvcmUvQ2hhbmdlTG9nCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvQ2hhbmdlTG9n CShyZXZpc2lvbiA2MDEwMCkKKysrIFdlYkNvcmUvQ2hhbmdlTG9nCSh3b3JraW5nIGNvcHkpCkBA IC0xLDMgKzEsMjIgQEAKKzIwMTAtMDUtMjQgIEVucmljYSBDYXN1Y2NpICA8ZW5yaWNhQGFwcGxl LmNvbT4KKworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICBS RUdSRVNTSU9OKDUxNTIyKTogdHlwaW5nIGF0IHRoZSBlbmQgb2YgYSBsaW5lIGluIGRlc2lnbk1v ZGUgZG9jdW1lbnRzIGlzICp2ZXJ5KiBzbG93LgorICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0 Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MzYwMzcKKyAgICAgICAgPHJkYXI6Ly9wcm9ibGVtLzgwMjI4 ODc+CisKKyAgICAgICAgVGhlIHBlcmZvcm1hbmNlIHJlZ3Jlc3Npb24gd2FzIHRyYWNlZCB0byBy NTE1MjIgYnV0IHRoaXMgaXMgbm90IGVudGlyZWx5IHRydWUuIFRoYXQgcmV2aXNpb24gaW50cm9k dWNlZCwgYW1vbmcgb3RoZXIgdGhpbmdzLAorICAgICAgICBhZGRpdGlvbmFsIGNoZWNrcyBpbiB0 aGUgbWV0aG9kIGlzQ2FuZGlkYXRlIG9mIGJvdGggUG9zaXRpb24gYW5kIFBvc2l0aW9uSXRlcmF0 b3IgY2xhc3NlcyB0byBzdXBwb3J0IHNjZW5hcmlvcyBvZiBtaXhlZCBlZGl0YWJpbGl0eQorICAg ICAgICB0aGF0IHdlcmUgbm90IGFsbG93ZWQgYmVmb3JlLiBUaGlzIGNoYW5nZSB1bmNvdmVyZWQg YW4gdW5kZXJseWluZyBpc3N1ZSB3aXRoIHRoZSBkZWNyZW1lbnQgbWV0aG9kIG9mIFBvc2l0aW9u SXRlcmF0b3IsIHRoYXQgaW4gc29tZQorICAgICAgICBjYXNlcyB3b3VsZCBpdGVyYXRlIHRocm91 Z2ggZXZlcnkgcG9zaXRpb24gYXMgb2Zmc2V0IGluIGEgYmxvY2sgYmVmb3JlIG1vdmluZyB0byB0 aGUgbGFzdCBjaGlsZCBpbiB0aGUgYmxvY2suCisgICAgICAgIFRoaXMgd2FzIGV4YWN0bHkgdGhl IGNhc2Ugb2YgdGhlIGF0dGFjaGVkIHRlc3QgY2FzZSwgd2hlcmUsIHRyeWluZyB0byBjaGVjayBp ZiB0aGUgY2FyZXQgd2FzIHBsYWNlZCBhdCB0aGUgZW5kIG9mIGEgYmxvY2ssIHdlIHdlcmUgZXhh bWluaW5nCisgICAgICAgIGV2ZXJ5IHBvc2l0aW9uIGluIHRoZSBibG9jayBiZWZvcmUgY29uc2lk ZXJpbmcgdGhlIGxhc3QgdHJ1ZSBwb3NpdGlvbiBpbiB0aGUgYmxvY2suCisgICAgICAgIFRoZSBw ZXJmb3JtYW5jZSB3YXMgbGluZWFyIHdpdGggdGhlIG51bWJlciBvZiBjaGlsZCBub2RlcyBpbiB0 aGUgYmxvY2ssIGluc3RlYWQgb2YgY29uc3RhbnQuCisgICAgICAgIAorICAgICAgICAqIGRvbS9Q b3NpdGlvbkl0ZXJhdG9yLmNwcDoKKyAgICAgICAgKFdlYkNvcmU6OlBvc2l0aW9uSXRlcmF0b3I6 OmRlY3JlbWVudCk6CisKIDIwMTAtMDUtMjQgIEplciBOb2JsZSAgPGplci5ub2JsZUBhcHBsZS5j b20+CiAKICAgICAgICAgTm8gcmV2aWV3OyBidWlsZCBmaXggb25seS4KSW5kZXg6IFdlYkNvcmUv ZG9tL1Bvc2l0aW9uSXRlcmF0b3IuY3BwCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvZG9tL1Bvc2l0 aW9uSXRlcmF0b3IuY3BwCShyZXZpc2lvbiA2MDA4NikKKysrIFdlYkNvcmUvZG9tL1Bvc2l0aW9u SXRlcmF0b3IuY3BwCSh3b3JraW5nIGNvcHkpCkBAIC04NCwxNSArODQsMTQgQEAgdm9pZCBQb3Np dGlvbkl0ZXJhdG9yOjpkZWNyZW1lbnQoKQogICAgICAgICB9CiAgICAgICAgIHJldHVybjsKICAg ICB9Ci0KLSAgICBpZiAobV9vZmZzZXRJbkFuY2hvcikgewotICAgICAgICBtX29mZnNldEluQW5j aG9yID0gUG9zaXRpb246OnVuY2hlY2tlZFByZXZpb3VzT2Zmc2V0KG1fYW5jaG9yTm9kZSwgbV9v ZmZzZXRJbkFuY2hvcik7CisgICAgCisgICAgaWYgKG1fYW5jaG9yTm9kZS0+aGFzQ2hpbGROb2Rl cygpKSB7CisgICAgICAgIG1fYW5jaG9yTm9kZSA9IG1fYW5jaG9yTm9kZS0+bGFzdENoaWxkKCk7 CisgICAgICAgIG1fb2Zmc2V0SW5BbmNob3IgPSAobV9hbmNob3JOb2RlLT5oYXNDaGlsZE5vZGVz KCkpPyAwOiBsYXN0T2Zmc2V0Rm9yRWRpdGluZyhtX2FuY2hvck5vZGUpOwogICAgIH0gZWxzZSB7 Ci0gICAgICAgIGlmIChtX2FuY2hvck5vZGUtPmhhc0NoaWxkTm9kZXMoKSkgewotICAgICAgICAg ICAgbV9hbmNob3JOb2RlID0gbV9hbmNob3JOb2RlLT5sYXN0Q2hpbGQoKTsKLSAgICAgICAgICAg IGlmICghbV9hbmNob3JOb2RlLT5oYXNDaGlsZE5vZGVzKCkpCi0gICAgICAgICAgICAgICAgbV9v ZmZzZXRJbkFuY2hvciA9IGxhc3RPZmZzZXRGb3JFZGl0aW5nKG1fYW5jaG9yTm9kZSk7Ci0gICAg ICAgIH0gZWxzZSB7CisgICAgICAgIGlmIChtX29mZnNldEluQW5jaG9yKQorICAgICAgICAgICAg bV9vZmZzZXRJbkFuY2hvciA9IFBvc2l0aW9uOjp1bmNoZWNrZWRQcmV2aW91c09mZnNldChtX2Fu Y2hvck5vZGUsIG1fb2Zmc2V0SW5BbmNob3IpOworICAgICAgICBlbHNlIHsKICAgICAgICAgICAg IG1fbm9kZUFmdGVyUG9zaXRpb25JbkFuY2hvciA9IG1fYW5jaG9yTm9kZTsKICAgICAgICAgICAg IG1fYW5jaG9yTm9kZSA9IG1fYW5jaG9yTm9kZS0+cGFyZW50Tm9kZSgpOwogICAgICAgICB9Cg==