13664 2007-05-10 14:55:18 -0700 REGRESSION: Extra letter in Webkit/Spell Catcher Shorthand (abbreviation) expansion 2007-08-08 17:03:37 -0700 1 1 1 Unclassified WebKit HTML Editing 523.x (Safari 3) Mac OS X 10.4 RESOLVED FIXED InRadar, Regression P1 Normal --- 14457 1 chetgw oliver adele ap chetgw evan justin.garcia oliver rob ruben oldest_to_newest 10390 0 chetgw 2007-05-10 14:55:18 -0700 When composing a message in Gmail with Safari/Webkit or Mailplane (beta), typing a Spell Catcher abbreviation causes the first letter of the abbreviation to be appended to the expansion. E.g. if I type “btw“ it gets expanded to “bBy the way”. This does not happen in Camino nor in any word processor/text editor that I have tried. Chet Safari 2.0.4; Spell Catcher 10.2.3 10145 1 ddkilzer 2007-05-12 22:32:06 -0700 Chet, does this still happen with a WebKit Nightly build? http://nightly.webkit.org/ 10129 2 evan 2007-05-12 22:52:50 -0700 (In reply to comment #0) > When composing a message in Gmail with Safari/Webkit or Mailplane (beta), > typing a Spell Catcher abbreviation causes the first letter of the abbreviation > to be appended to the expansion. E.g. if I type “btw“ it gets expanded to “bBy > the way”. This does not happen in Camino nor in any word processor/text editor > that I have tried. > > Chet > > Safari 2.0.4; Spell Catcher 10.2.3 > Hi folks, been a while since I've last looked at the state of text input with WebKit... First off, tell me whether the Spell Catcher preference (Interactive pane, Typing tab) to "Make replacements directly (without backspacing) where possible" is selected (for Safari if you have it in the Applications drawer) or not. This preference exists specifically to work-around bug 4681. Figuring out exactly what's wrong depends largely on whether this preference is selected. It may also be nice to know what happens when you change that preference... 10091 3 chetgw 2007-05-13 08:30:57 -0700 RE: Comment 1 Yes, I have used nightly builds 20057, 20814, & 21240; all with the same result. RE: Comment 2 Checking the "Make replacements directly (without backspacing) where possible" causes the abbreviation to remain, followed by a space and the expansion such as below: btw By the way, Chet 10009 4 evan 2007-05-14 18:14:46 -0700 (In reply to comment #3) > > Checking the "Make replacements directly (without backspacing) where > possible" causes the abbreviation to remain, followed by a space and the > expansion such as below: > > btw By the way, > OK, that behavior isn't one I've seen before - at least not with the WebKit builds I was testing with way back when. Can you try a couple things for me? Select the "Prevent double spaces" in Spell Catcher Preferences, Interactive, Automatic tab. Tell me whether the 2nd..nth space after typing a space are suppressed or not (and whether all or just some are suppressed or "allowed" through. Might also be useful to know whether the "Suppress separator" option for individual shorthands (checkbox is below the expansion area in the Shorthand editor window) works or not. Also see whether typing a tab instead of space as the separator behaves any differently. If WebKit isn't properly suppressing characters, that is a very serious (and new to me) bug that needs to be filed (and fixed!) ASAP. The consequences of this sort of "not suppressing characters when an input method want them suppressed are severe... Evan 10002 5 chetgw 2007-05-14 20:41:20 -0700 (In reply to comment #4) l. “Prevent double spaces” has no effect; i.e. typing two or three spaces after a word leaves two or three spaces in the text. 2. "Suppress separator" works as expected but again, the first letter of the abbreviation is left in place. 3. “typing a tab instead of a space” causes some really bizarre things to happen. The first time I tried it, the abbreviation stayed in place but the expansion ended up in the Google Search box at the top of the window!??! I abandoned that draft and opened a new one. This time the abbreviation remained in place but with no expansion and the TAB caused the cursor to flip to the Google Search box. Subsequent attempts to duplicate the results of the first time TAB was used as the separator just caused the cursor to end up in the Google Search box without the expansion. Mailplane has a preference item to ”Enable rich text editing by using Webkit nightly”. When this item is unchecked (disabled), all is well with the only problem that remains being that of using TAB as the separator. In this case, the expansion is fine but the cursor is still placed in the Google Search box. Chet 9813 6 evan 2007-05-16 15:48:29 -0700 (In reply to comment #5) > (In reply to comment #4) > l. “Prevent double spaces” has no effect; i.e. typing two or three spaces after > a word leaves two or three spaces in the text. > > 2. "Suppress separator" works as expected but again, the first letter of the > abbreviation is left in place. > > 3. “typing a tab instead of a space” causes some really bizarre things to > happen. The first time I tried it, the abbreviation stayed in place but the > expansion ended up in the Google Search box at the top of the window!??! I > abandoned that draft and opened a new one. This time the abbreviation remained > in place but with no expansion and the TAB caused the cursor to flip to the > Google Search box. Subsequent attempts to duplicate the results of the first > time TAB was used as the separator just caused the cursor to end up in the > Google Search box without the expansion. > > Mailplane has a preference item to ”Enable rich text editing by using Webkit > nightly”. When this item is unchecked (disabled), all is well with the only > problem that remains being that of using TAB as the separator. In this case, > the expansion is fine but the cursor is still placed in the Google Search box. > > Chet > OK, well, this seems to confirm my guess that keystrokes are not being suppressed when an input method "says" they should be. This is a very, very bad thing. Since it's so nasty, I'll try to find time in the next week to build the latest WebKit and actually do some real testing to confirm this and see if I can find a solution. Unless someone else wants to... Thanks for helping with this, as it absolutely must be fixed or input methods simply aren't going to work properly at all. 9692 7 ddkilzer 2007-05-17 08:17:05 -0700 (In reply to comment #6) > OK, well, this seems to confirm my guess that keystrokes are not being > suppressed when an input method "says" they should be. > > This is a very, very bad thing. Could you write a small HTML test case demonstrating the incorrect behavior? That would be most helpful. > Since it's so nasty, I'll try to find time in the next week to build the latest > WebKit and actually do some real testing to confirm this and see if I can find > a solution. Unless someone else wants to... Actually, you may download nightly WebKit builds here: http://nightly.webkit.org/. Simply download the DMG, mount it, and double-click on the gold Safari icon to test. > Thanks for helping with this, as it absolutely must be fixed or input methods > simply aren't going to work properly at all. A working test case attached to this bug will be the fastest path (other than writing a patch yourself!) to getting this bug fixed. Thanks! 9426 8 evan 2007-05-22 11:58:00 -0700 (In reply to comment #7) > Could you write a small HTML test case demonstrating the incorrect behavior? > That would be most helpful. > This is often easier said than done wrt text input-related problems... > Actually, you may download nightly WebKit builds here: > http://nightly.webkit.org/. Simply download the DMG, mount it, and > double-click on the gold Safari icon to test. > I really needed to see the source to at least begin to figure out what's going on (which I've done, but now have various questions about). > A working test case attached to this bug will be the fastest path (other than > writing a patch yourself!) to getting this bug fixed. Thanks! > I probably can't write it myself without some help - so Help! - OK, looking at the source, I some questions/comments: 1. There is a comment in -insertText: // insertText can be called from an input method or from normal key event processing // If its from normal key event processing, we may need to save the action to perform it later. // If its from an input method, then we should go ahead and insert the text now. // We assume it's from the input method if we have marked text. // FIXME: In theory, this could be wrong for some input methods, so we should try to find // another way to determine if the call is from the input method The FIXME note is absolutely accurate, so this code must be FIXME'd. Testing for marked text is not sufficient. 2. I need to understand the meaning of WebHTMLViewInterpretKeyEventsParameters. What it contains, why it's there, what it's supposed to be used for. 3. I'm not certain what the idea behind the two different code paths for "isFromInputMethod"/"shouldSaveCommand" etc. This is new since I worked on this stuff way back when, so I'm not familiar with why this was implemented. 4. It looks like the shouldSaveCommand flag is related to either UpdateActiveInputArea calls and/or the input method returning whether or not it actually handled an event. Anyone know what this is all about? Not entirely related, but still relevant, this comment: // We don't support inserting an attributed string but input methods don't appear to require this. will be incorrect in the future. AttributedStrings MUST be supported here. I have made some changes that fix this particular problem with Spell Catcher, but without knowing exactly what's going on (answers to the above questions, at minimum) have no idea if they will break other input methods... 7511 9 rob 2007-06-14 15:38:39 -0700 Please forward my support for your efforts to get this bug fixed. I rely on Spell Catcher's short hands for most of my work. To me it is a mission critical app. I installed Safari 3 and it has some features that are so compelling I don't want to uninstall it. Most of all, the ability to resize text entry fields on the fly. I experience the same problems in Mail as have been described in detail in http://bugs.webkit.org/show_bug.cgi?id=13664 I get the sense from this thread, that the bug in web kit will be fixed but that it is hard, and may take some time. I will vote for the bug to be fixed. Good luck. My example is below: the letters "siggg" are the text of my shorthand which should be suppressed. So therefore it is a problem here in Safari as well as mail. siggg Robert Whyte Director, Web Development ToadShow Pty Ltd e rob@toadshow.com.au p 07 3004 7900 f 07 3846 1220 m 0409 055 325 w http://www.toadshow.com.au/ If for any reason your email doesn't get through to me, try rob04@toadshow.com.au 6636 10 ap 2007-06-23 00:08:00 -0700 (In reply to comment #6) > OK, well, this seems to confirm my guess that keystrokes are not being > suppressed when an input method "says" they should be. > > This is a very, very bad thing. I think this is a known bug that's indeed affecting other input methods, and that is being investigated. Marking as a regression, since Spell Catcher shorthands seem to work fine in shipping Safari (for both AppKit-based text inputs and contenteditable HTML). 6591 11 rwoelk 2007-06-23 07:13:17 -0700 Please fix webkit to address address SpellCatcher's input issues as outlined here. SpellCatcher is mission critical for so many of us who write for a living. If not fixed in a timely manner, this could be a deal breaker in staying within Apple's platform. 6560 12 ddkilzer 2007-06-23 11:41:09 -0700 <rdar://problem/5290113> 5838 13 albertjmenkveld 2007-06-30 12:15:41 -0700 Please fix this issue, as I do currently not use Apple Safari 3.0, because of this issue. -Albert 5835 14 ap 2007-06-30 14:06:40 -0700 It seems that Oliver's patch didn't fix this problem - I can still reproduce it. 5831 15 evan 2007-06-30 14:31:23 -0700 (In reply to comment #14) > It seems that Oliver's patch didn't fix this problem - I can still reproduce > it. > What/where's the patch? I have figured out a way to get this working with Spell Catcher, but due to my lack of knowledge about the various private parameters (WebHTMLViewInterpretKeyEventsParameters ) being passed around (-insertText, -doCommandBySelector), I have no idea whether it's going to break other input methods. In any case, it looks to me like the value of shouldSaveCommand is the key to figure out whether the text/command is the result of an UpdateActiveInputArea event. AND it looks like it's currently being used incorrectly. And checking whether there's marked text or not to decide whether the event is from an input method is just plain wrong. Input methods can send text via UAIA without maintaining an active input area at all. I'm hesitant to post a patch without knowing more about the reasoning behind the changes that have been made since I last looked at this stuff. But if you want me to post what I've got, I certainly can. 5825 16 oliver 2007-06-30 17:32:59 -0700 *** Bug 4681 has been marked as a duplicate of this bug. *** 5826 17 oliver 2007-06-30 17:36:08 -0700 Evan, we were doing substantial work to fix issues with international text support, i guess ap thought these would help. Unfortunately the symptoms experienced by SpellChecker are unrelated to our International text support problems. Looking at this, you're right it is just the return of 4681. Technically i should dup this to that, but there's more discussion (and a radar) associated with this so am marking 4681 as a dupe of this. I wish there was some documentation of these "secret" attributes :-/ It looks like we should be able to do something similar to the replacement of marked text, in this case, but it still irritates me. 5807 18 oliver 2007-06-30 22:17:40 -0700 Evan do you esxpect the space character to be inserted before or after your inputmethod logic occurs? 5808 19 evan 2007-06-30 23:41:18 -0700 (In reply to comment #18) > Evan do you esxpect the space character to be inserted before or after your > inputmethod logic occurs? > This is what Spell Catcher does when expanding a shorthand abbreviation - as an example say that typing "fyi" should result in "for your information": 1. In an application that does NOT support TSM document access and the required sendRange parameter to the UpdateActiveInputArea event (the current state of WebHTMLView, as it doesn't support the NSTextInputReplacementRangeAttributeName attribute): - user types f, then y, then i, then a whitespace or newline separator (we'll say it's a space for illustrative purposes). - Spell Catcher checks the "fyi" when it receives the space typed afterwards, and finds the expansion "for your information". - After determining it's an abbreviation that needs to be expanded, Spell Catcher SUPPRESSES the space by returning to TSM that it has handled the event in its entirety. THIS IS WHERE WebView is screwing up. No UpdateActiveInputArea event has been sent (yet), the input method is simply returning a non-zero ComponentResult from its Event dispatch call, which MUST be respected by the application. Somehow the event is still getting through, even though TSM has been told that it was handled, and therefore should NOT be handed off to the client app. - Spell Catcher calculates how many backspace characters need to be posted to backspace over the "fyi" that was typed. REMEMBER, since the space character has been suppressed (normally, in a properly functioning app) only 3 backspaces need to be posted. Backspace and other control characters are handled very differently in Cocoa apps vs. (most) Carbon apps if sent via an UAIA call. We don't want ASCII 8 inserted into the document's text (tab characters pose a particular problem here, but I digress). so we post them with the CGRemote APIs. They need to be handled by the app as physical keystrokes. =====THIS IS WHY the first letter of the abbreviation is "left behind" - take a look at the original problem reports===== - NOW, in an app that supports inline input via UpdateActiveInputArea (WebView does at least support this), the expansion "for your information " is sent to the application via an UpdateActiveInputArea call, specifying that all the text should be dumped immediately - no inline area (marked text) should result. This a prime example of text coming from an input method, and there is NO marked text in the document before or afterward. +++ ALSO NOTE CAREFULLY that the suppressed space following the f y i that was typed, is appended to the expansion - there are a number of important reasons it's done this way, no need to get into that aspect now, though. So the basic problem stems from the fact that "input method-handled" events are still getting through to and processed by WebView. If an input method wants an event suppressed, the app must obey or really nothing is going to work properly from that point on. This is the basis of many Spell Catcher features - preventing double spaces, turning straight quotes into curly quotes, automatic capitalization changes (in certain circumstances). This is all broken because of this bug, and it's something that can absolutely not be worked-around at the input method level. The TSM Doc Access-aware situation is far more optimal, as Spell Catcher can avoid backspacing entirely. It just replaces the "fyi " directly in the text with "for your information ". No fuss, no muss, instantaneous. That's why NSTextInputReplacementRangeAttributeName should be supported, but supporting it has absolutely no relevance or relation to fixing this particular problem. I don't think this bug and Bug 4681 are really duplicates. But they are in the same very basic text input handling arena, and both need to be fixed. Fix this one first, then optimize by supporting NSTextInputReplacementRangeAttributeName. Supporting NSTextInputReplacementRangeAttributeName without fixing this may get Spell Catcher to work right, but other input methods that don't look for doc access support in order to perform better will still have this not-suppressing-the-character-I-told-you-to-suppress issues. Phew! 5785 20 oliver 2007-07-01 15:25:26 -0700 The problem i've encountered is that (afaict) is when handling the replacement i end up with "fyi " => "fFor your information " If you are actually inserting the space i'm guessing that we aren't correctly detecting that you have consumed the space. 5782 21 oliver 2007-07-01 15:36:26 -0700 Hmmm, something i've thought i needed to do is treat all key events as being consumed by the IM even if there isn't a marked region. This fixes the problem, but may have a substantial impact on non-IM based input so will require substantial testing. 5766 22 oliver 2007-07-01 18:02:07 -0700 Righto, there are two bugs involved, one, the fact they we aren't handling NSTextInputReplacementRangeAttributeName in insertText: The other is bug 14457 which is what causes the first character of the autocorrect trigger to remain after the autocorrect 5753 23 oliver 2007-07-01 22:27:25 -0700 Righto, 14457 should be fixed, which means the backspace route should work. We now need to make the replacement range work. 5756 24 oliver 2007-07-01 22:28:47 -0700 *** Bug 4681 has been marked as a duplicate of this bug. *** 5757 25 15343 oliver 2007-07-01 23:37:33 -0700 Created attachment 15343 First run at fixing it First run at fixing this problem. 5758 26 15343 justin.garcia 2007-07-01 23:46:29 -0700 Comment on attachment 15343 First run at fixing it // We don't support inserting an attributed string but input methods don't appear to require this. Might want to remove this comment. r=me 5759 27 justin.garcia 2007-07-01 23:48:11 -0700 (In reply to comment #26) > Might want to remove this comment. Oops nevermind. 5760 28 15344 oliver 2007-07-02 00:00:24 -0700 Created attachment 15344 Minor update Whoops, if we get a replacement range we must not be getting "real" keyboard events, so assume it's from an IM. What i would give to be able to have regression tests for IMs, but don't have time to be able to do the work necessary to get such a system in place. 5744 29 oliver 2007-07-02 00:43:36 -0700 Landed r23926 5586 30 evan 2007-07-04 14:49:50 -0700 (In reply to comment #28) > Created an attachment (id=15344) [edit] > Minor update > > Whoops, if we get a replacement range we must not be getting "real" keyboard > events, so assume it's from an IM. > > What i would give to be able to have regression tests for IMs, but don't have > time to be able to do the work necessary to get such a system in place. > Thanks Oliver! After some testing all seems *almost* perfect. There is an issue with the handling of the replacement range parameter, in that the selection is changed afterwards. This is a definite problem (NSTextView, MLTE, WASTE and BBEdit all maintain the selection properly), as is cannot be assumed that the replacement range is always at the insertion point (and indeed, there may be a selection not just an insertion point). Should I file a separate bug? 5509 31 oliver 2007-07-05 12:30:31 -0700 Yes, file a separate bug. I assume this will cause the scrolling problem you referred to in #4681 and possibly an unwanted selection event will be fired -- this possibly hits the marked text path as well. 4807 32 js.fink 2007-07-14 03:01:41 -0700 This is not resolved/fixed. The problem persists in the latest Safari 3. 4810 33 ap 2007-07-14 05:28:13 -0700 Please use a nightly build from <http://nightly.webkit.org>. 4757 34 oliver 2007-07-14 15:09:33 -0700 Jon, this fix has not been released in a release version of webkit yet, you'll need to test against a nightly -- see http://nightly.webkit.org 3700 35 ddkilzer 2007-07-25 22:25:51 -0700 (In reply to comment #32) > This is not resolved/fixed. The problem persists in the latest Safari 3. Jon, please test this with a recent WebKit nightly and report back the results here. Thanks! 2859 36 ddkilzer 2007-08-07 21:30:35 -0700 Could someone please verify that this issue is fixed with WebKit Nightly r23926 or later? Thanks! 2851 37 chetgw 2007-08-07 22:07:41 -0700 (In reply to comment #36) > Could someone please verify that this issue is fixed with WebKit Nightly r23926 > or later? Thanks! > Sorry, I’ve been delinquent on this matter. Webkit r24260 works in Mailplane beta. I have not tried in Mail.app nor Safari 3.0 beta. Chet 2792 38 ddkilzer 2007-08-08 17:03:37 -0700 (In reply to comment #37) > Sorry, I’ve been delinquent on this matter. Webkit r24260 works in Mailplane > beta. I have not tried in Mail.app nor Safari 3.0 beta. Thanks!! 15343 2007-07-01 23:37:33 -0700 2007-07-02 00:00:24 -0700 First run at fixing it insertTextReplace.patch text/plain 2151 oliver SW5kZXg6IFdlYktpdC9DaGFuZ2VMb2cKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gV2ViS2l0L0NoYW5nZUxvZwko cmV2aXNpb24gMjM5MjUpCisrKyBXZWJLaXQvQ2hhbmdlTG9nCSh3b3JraW5nIGNvcHkpCkBAIC0x LDMgKzEsMTggQEAKKzIwMDctMDctMDEgIE9saXZlciBIdW50ICA8b2xpdmVyQGFwcGxlLmNvbT4K KworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICBGaXggZm9y IAorICAgICAgICAgIDxyZGFyOi8vcHJvYmxlbS81MjkwMTEzPiBXZWJLaXQgZG9lcyBub3QgY29y cmVjdGx5IGhhbmRsZSByZXBsYWNlbWVudCByYW5nZXMgZnJvbSB0aGUgSU0gaW4gLVtXZWJIVE1M VmlldyBpbnNlcnRUZXh0Ol0KKyAgICAgICAgICBodHRwOi8vYnVncy53ZWJraXQub3JnL3Nob3df YnVnLmNnaT9pZD0xMzY2NAorCisgICAgICAgIFdlIHJlcGxpY2F0ZSB0aGUgbG9naWMgb2YgLVtX ZWJIVE1MVmlldyBzZXRNYXJrZWRUZXh0OnNlbGVjdGVkUmFuZ2U6XSB0byBoYW5kbGUgdGhlIElu cHV0IE1ldGhvZCAKKyAgICAgICAgZmVlZGluZyB1cyBhIHJlcGxhY2VtZW50IHN0cmluZyB0aHJv dWdoIGluc2VydFRleHQ6IHNvIHdlIGNhbiBoYW5kbGUgSU1zIHRoYXQgdXNlIGluc2VydFRleHQg dG8KKyAgICAgICAgcmVwbGFjZSB0ZXh0LgorCisgICAgICAgICogV2ViVmlldy9XZWJIVE1MVmll dy5tbToKKyAgICAgICAgKC1bV2ViSFRNTFZpZXcgaW5zZXJ0VGV4dDpdKToKKwogMjAwNy0wNy0w MSAgT2xpdmVyIEh1bnQgIDxvbGl2ZXJAYXBwbGUuY29tPgogCiAgICAgICAgIFJldmlld2VkIGJ5 IEFsZXhleS4KSW5kZXg6IFdlYktpdC9XZWJWaWV3L1dlYkhUTUxWaWV3Lm1tCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0K LS0tIFdlYktpdC9XZWJWaWV3L1dlYkhUTUxWaWV3Lm1tCShyZXZpc2lvbiAyMzkyNCkKKysrIFdl YktpdC9XZWJWaWV3L1dlYkhUTUxWaWV3Lm1tCSh3b3JraW5nIGNvcHkpCkBAIC01NDc1LDkgKzU0 NzUsMTYgQEAgQk9PTCBpc1RleHRJbnB1dChGcmFtZSAqY29yZUZyYW1lKQogCiAgICAgLy8gV2Ug ZG9uJ3Qgc3VwcG9ydCBpbnNlcnRpbmcgYW4gYXR0cmlidXRlZCBzdHJpbmcgYnV0IGlucHV0IG1l dGhvZHMgZG9uJ3QgYXBwZWFyIHRvIHJlcXVpcmUgdGhpcy4KICAgICBOU1N0cmluZyAqdGV4dDsK LSAgICBpZiAoW3N0cmluZyBpc0tpbmRPZkNsYXNzOltOU0F0dHJpYnV0ZWRTdHJpbmcgY2xhc3Nd XSkKKyAgICBpZiAoW3N0cmluZyBpc0tpbmRPZkNsYXNzOltOU0F0dHJpYnV0ZWRTdHJpbmcgY2xh c3NdXSkgewogICAgICAgICB0ZXh0ID0gW3N0cmluZyBzdHJpbmddOwotICAgIGVsc2UKKyAgICAg ICAgLy8gV2UgZGVhbCB3aXRoIHRoZSBOU1RleHRJbnB1dFJlcGxhY2VtZW50UmFuZ2VBdHRyaWJ1 dGVOYW1lIGF0dHJpYnV0ZSBmcm9tIE5TQXR0cmlidXRlZFN0cmluZyBoZXJlCisgICAgICAgIC8v IHNpbXBseSBiZWNhdXNlIGl0IGlzIHVzZWQgYnkgYXQgbGVhc3Qgb25lIElucHV0IE1ldGhvZCAt LSBpdCBjb3JyZXNvbmRzIHRvIHRoZSBrRXZlbnRQYXJhbVRleHRJbnB1dFNlbmRSZXBsYWNlUmFu Z2UKKyAgICAgICAgLy8gZXZlbnQgaW4gVFNNLiAgVGhpcyBiZWhhdmlvdXIgbWF0Y2hlcyB0aGF0 IG9mIC1bV2ViSFRNTFZpZXcgc2V0TWFya2VkVGV4dDpzZWxlY3RlZFJhbmdlOl0gd2hlbiBpdCBy ZWNlaXZlcyBhbgorICAgICAgICAvLyBOU0F0dHJpYnV0ZWRTdHJpbmcKKyAgICAgICAgTlNTdHJp bmcgKnJhbmdlU3RyaW5nID0gW3N0cmluZyBhdHRyaWJ1dGU6TlNUZXh0SW5wdXRSZXBsYWNlbWVu dFJhbmdlQXR0cmlidXRlTmFtZSBhdEluZGV4OjAgbG9uZ2VzdEVmZmVjdGl2ZVJhbmdlOk5VTEwg aW5SYW5nZTpOU01ha2VSYW5nZSgwLCBbdGV4dCBsZW5ndGhdKV07CisgICAgICAgIGlmIChyYW5n ZVN0cmluZykgCisgICAgICAgICAgICBbW3NlbGYgX2JyaWRnZV0gc2VsZWN0TlNSYW5nZTpOU1Jh bmdlRnJvbVN0cmluZyhyYW5nZVN0cmluZyldOworICAgIH0gZWxzZQogICAgICAgICB0ZXh0ID0g c3RyaW5nOwogCiAgICAgYm9vbCBldmVudEhhbmRsZWQgPSBmYWxzZTsK 15344 2007-07-02 00:00:24 -0700 2007-07-02 00:29:22 -0700 Minor update insertTextReplace.patch text/plain 2755 oliver SW5kZXg6IFdlYktpdC9DaGFuZ2VMb2cKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gV2ViS2l0L0NoYW5nZUxvZwko cmV2aXNpb24gMjM5MjUpCisrKyBXZWJLaXQvQ2hhbmdlTG9nCSh3b3JraW5nIGNvcHkpCkBAIC0x LDMgKzEsMTggQEAKKzIwMDctMDctMDEgIE9saXZlciBIdW50ICA8b2xpdmVyQGFwcGxlLmNvbT4K KworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICBGaXggZm9y IAorICAgICAgICAgIDxyZGFyOi8vcHJvYmxlbS81MjkwMTEzPiBXZWJLaXQgZG9lcyBub3QgY29y cmVjdGx5IGhhbmRsZSByZXBsYWNlbWVudCByYW5nZXMgZnJvbSB0aGUgSU0gaW4gLVtXZWJIVE1M VmlldyBpbnNlcnRUZXh0Ol0KKyAgICAgICAgICBodHRwOi8vYnVncy53ZWJraXQub3JnL3Nob3df YnVnLmNnaT9pZD0xMzY2NAorCisgICAgICAgIFdlIHJlcGxpY2F0ZSB0aGUgbG9naWMgb2YgLVtX ZWJIVE1MVmlldyBzZXRNYXJrZWRUZXh0OnNlbGVjdGVkUmFuZ2U6XSB0byBoYW5kbGUgdGhlIElu cHV0IE1ldGhvZCAKKyAgICAgICAgZmVlZGluZyB1cyBhIHJlcGxhY2VtZW50IHN0cmluZyB0aHJv dWdoIGluc2VydFRleHQ6IHNvIHdlIGNhbiBoYW5kbGUgSU1zIHRoYXQgdXNlIGluc2VydFRleHQg dG8KKyAgICAgICAgcmVwbGFjZSB0ZXh0LgorCisgICAgICAgICogV2ViVmlldy9XZWJIVE1MVmll dy5tbToKKyAgICAgICAgKC1bV2ViSFRNTFZpZXcgaW5zZXJ0VGV4dDpdKToKKwogMjAwNy0wNy0w MSAgT2xpdmVyIEh1bnQgIDxvbGl2ZXJAYXBwbGUuY29tPgogCiAgICAgICAgIFJldmlld2VkIGJ5 IEFsZXhleS4KSW5kZXg6IFdlYktpdC9XZWJWaWV3L1dlYkhUTUxWaWV3Lm1tCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0K LS0tIFdlYktpdC9XZWJWaWV3L1dlYkhUTUxWaWV3Lm1tCShyZXZpc2lvbiAyMzkyNCkKKysrIFdl YktpdC9XZWJWaWV3L1dlYkhUTUxWaWV3Lm1tCSh3b3JraW5nIGNvcHkpCkBAIC01NDc1LDkgKzU0 NzUsMTkgQEAgQk9PTCBpc1RleHRJbnB1dChGcmFtZSAqY29yZUZyYW1lKQogCiAgICAgLy8gV2Ug ZG9uJ3Qgc3VwcG9ydCBpbnNlcnRpbmcgYW4gYXR0cmlidXRlZCBzdHJpbmcgYnV0IGlucHV0IG1l dGhvZHMgZG9uJ3QgYXBwZWFyIHRvIHJlcXVpcmUgdGhpcy4KICAgICBOU1N0cmluZyAqdGV4dDsK LSAgICBpZiAoW3N0cmluZyBpc0tpbmRPZkNsYXNzOltOU0F0dHJpYnV0ZWRTdHJpbmcgY2xhc3Nd XSkKKyAgICBib29sIGlzRnJvbUlucHV0TWV0aG9kID0gW3NlbGYgaGFzTWFya2VkVGV4dF07Cisg ICAgaWYgKFtzdHJpbmcgaXNLaW5kT2ZDbGFzczpbTlNBdHRyaWJ1dGVkU3RyaW5nIGNsYXNzXV0p IHsKICAgICAgICAgdGV4dCA9IFtzdHJpbmcgc3RyaW5nXTsKLSAgICBlbHNlCisgICAgICAgIC8v IFdlIGRlYWwgd2l0aCB0aGUgTlNUZXh0SW5wdXRSZXBsYWNlbWVudFJhbmdlQXR0cmlidXRlTmFt ZSBhdHRyaWJ1dGUgZnJvbSBOU0F0dHJpYnV0ZWRTdHJpbmcgaGVyZQorICAgICAgICAvLyBzaW1w bHkgYmVjYXVzZSBpdCBpcyB1c2VkIGJ5IGF0IGxlYXN0IG9uZSBJbnB1dCBNZXRob2QgLS0gaXQg Y29ycmVzb25kcyB0byB0aGUga0V2ZW50UGFyYW1UZXh0SW5wdXRTZW5kUmVwbGFjZVJhbmdlCisg ICAgICAgIC8vIGV2ZW50IGluIFRTTS4gIFRoaXMgYmVoYXZpb3VyIG1hdGNoZXMgdGhhdCBvZiAt W1dlYkhUTUxWaWV3IHNldE1hcmtlZFRleHQ6c2VsZWN0ZWRSYW5nZTpdIHdoZW4gaXQgcmVjZWl2 ZXMgYW4KKyAgICAgICAgLy8gTlNBdHRyaWJ1dGVkU3RyaW5nCisgICAgICAgIE5TU3RyaW5nICpy YW5nZVN0cmluZyA9IFtzdHJpbmcgYXR0cmlidXRlOk5TVGV4dElucHV0UmVwbGFjZW1lbnRSYW5n ZUF0dHJpYnV0ZU5hbWUgYXRJbmRleDowIGxvbmdlc3RFZmZlY3RpdmVSYW5nZTpOVUxMIGluUmFu Z2U6TlNNYWtlUmFuZ2UoMCwgW3RleHQgbGVuZ3RoXSldOworICAgICAgICBpZiAocmFuZ2VTdHJp bmcpIHsKKyAgICAgICAgICAgIFtbc2VsZiBfYnJpZGdlXSBzZWxlY3ROU1JhbmdlOk5TUmFuZ2VG cm9tU3RyaW5nKHJhbmdlU3RyaW5nKV07CisgICAgICAgICAgICBpc0Zyb21JbnB1dE1ldGhvZCA9 IFlFUzsKKyAgICAgICAgfQorICAgIH0gZWxzZQogICAgICAgICB0ZXh0ID0gc3RyaW5nOwogCiAg ICAgYm9vbCBldmVudEhhbmRsZWQgPSBmYWxzZTsKQEAgLTU0OTEsNyArNTUwMSw2IEBAIEJPT0wg aXNUZXh0SW5wdXQoRnJhbWUgKmNvcmVGcmFtZSkKICAgICAgICAgLy8gRklYTUU6IEluIHRoZW9y eSwgdGhpcyBjb3VsZCBiZSB3cm9uZyBmb3Igc29tZSBpbnB1dCBtZXRob2RzLCBzbyB3ZSBzaG91 bGQgdHJ5IHRvIGZpbmQKICAgICAgICAgLy8gYW5vdGhlciB3YXkgdG8gZGV0ZXJtaW5lIGlmIHRo ZSBjYWxsIGlzIGZyb20gdGhlIGlucHV0IG1ldGhvZAogICAgICAgICBib29sIHNob3VsZFNhdmVD b21tYW5kID0gcGFyYW1ldGVycyAmJiBwYXJhbWV0ZXJzLT5zaG91bGRTYXZlQ29tbWFuZDsKLSAg ICAgICAgYm9vbCBpc0Zyb21JbnB1dE1ldGhvZCA9IFtzZWxmIGhhc01hcmtlZFRleHRdOwogICAg ICAgICBpZiAoZXZlbnQgJiYgc2hvdWxkU2F2ZUNvbW1hbmQgJiYgIWlzRnJvbUlucHV0TWV0aG9k KSB7CiAgICAgICAgICAgICBLZXlwcmVzc0NvbW1hbmQgY29tbWFuZDsKICAgICAgICAgICAgIGNv bW1hbmQudGV4dCA9IHRleHQ7Cg==