23156 2009-01-06 17:19:58 -0800 Windows: No support for platform keyboard shortcut right shift + right control to set writing direction. 2010-06-10 16:38:29 -0700 1 1 1 Unclassified WebKit HTML Editing 528+ (Nightly build) PC Windows XP NEW PlatformOnly P2 Normal --- 1 xji webkit-unassigned ap hbono jshin mitz playmobil progame+wk oldest_to_newest 104675 0 xji 2009-01-06 17:19:58 -0800 Chrome bug: http://code.google.com/p/chromium/issues/detail?id=1845 Step to reproduce: 1. press "Compose Mail" in Gmail 2. focus cursor on the text area of the mail's body, press right shift + right ctrl. Expected result: Cursor should be moved from the left to the right of the text area. What happens: Cursor no movement Note: Every textbox/textarea (even with English text or no text at all) should be aligned to the right when pressing the right ctrl + right shift, and aligned to the left when pressing the left ctrl + left shift. 104729 1 mitz 2009-01-07 11:09:37 -0800 I think this bug is about the Windows convention that Ctrl+Shift changes the base writing direction (which indirectly affects alignment). Am I correct? Note that WebKit/mac has support for the Mac OS X key bindings for changing the base writing direction (see writingDirectionKeyBindingsEnabled() in WebHTMLView.mm and the methods that consult it). 104833 2 hbono 2009-01-07 19:32:50 -0800 Sorry not to have describe its details. This bug technically consists of two bugs: 1. We need to change the Windows convention of CTRL+SHIFT keys, including adding methods to distinguish left keys and right keys; 2. The WebCore::executeMakeTextDirectionLeftToRight() function (in EditorCommand.cpp) does not change the "dir" attribute of the selected node, as the Editor::setBaseWritingDirection() function does. It only changes its CSS attributes, such as "--webkit-direciton". So, the function causes a serious inconsistency between DOM attributes and CSS properties. To fix the second bug, we need to: (a) Change the WebCore::executeMakeTextDirectionLeftToRight() function to call the Editor::setBaseWritingDirection() function to change the writing direction, or; (b) Add code to the function to change the DOM attributes. Even though I have confirmed either option work, I would like to ask you which option is better. Regards, Hironori Bono 104834 3 mitz 2009-01-07 19:50:13 -0800 (In reply to comment #2) > Sorry not to have describe its details. > This bug technically consists of two bugs: Then it would be much better to have two separate bugs in Bugzilla about it. > 1. We need to change the Windows convention of CTRL+SHIFT keys, including > adding methods to distinguish left keys and right keys; Okay. Hopefully there is a higher-level way to describe the key combination for changing the writing direction (maybe it is even user-configurable), but this seems like a clear task: recognizing that the user has issued the command to change the writing direction. > 2. The WebCore::executeMakeTextDirectionLeftToRight() function (in > EditorCommand.cpp) does not change the "dir" attribute of the selected node, as > the Editor::setBaseWritingDirection() function does. It only changes its CSS > attributes, such as "--webkit-direciton". So, the function causes a serious > inconsistency between DOM attributes and CSS properties. I think you are mixing up two separate concepts: the "text" or "character-level" directionality and the "paragraph-level" or "base" writing direction. > To fix the second bug, we need to: > (a) Change the WebCore::executeMakeTextDirectionLeftToRight() function to call > the Editor::setBaseWritingDirection() function to change the writing direction, No, setting the text direction of a range should not change the paragraph-level writing direction. > or; > (b) Add code to the function to change the DOM attributes. I do not think that would be necessary. setBaseWritingDirection has the necessary code to achieve what the command does, in a way that as far as I can tell is compatible with IE. Perhaps some of your confusion stems from the fact that the character-level commands have a modern implementation as editor commands, and the paragraph-level commands have a lot of their logic (such as for validation and state checking) still in WebKit (in WebHTMLView.mm). I think a good first step could be to modernize the way the paragraph-level commands are implemented. I think that will make the differences between the concepts clearer and make addressing issue (1) easier. 104841 4 hbono 2009-01-07 22:08:08 -0800 > > (b) Add code to the function to change the DOM attributes. > > I do not think that would be necessary. setBaseWritingDirection has the > necessary code to achieve what the command does, in a way that as far as I can > tell is compatible with IE. Sorry for my stupid description. This "the function" means the WebCore::executeMakeTextDirectionLeftToRight() function. I noticed the Editor::setBaseWritingDirection() has code to change the DOM attributes. Regards, Hironori Bono 104842 5 mitz 2009-01-07 22:15:20 -0800 (In reply to comment #4) > > > (b) Add code to the function to change the DOM attributes. > > > > I do not think that would be necessary. setBaseWritingDirection has the > > necessary code to achieve what the command does, in a way that as far as I can > > tell is compatible with IE. > > Sorry for my stupid description. > This "the function" means the WebCore::executeMakeTextDirectionLeftToRight() > function. I noticed the Editor::setBaseWritingDirection() has code to change > the DOM attributes. executeMakeTextDirectionLeftToRight() implements functionality that, as far as I know, does not exist in other engines, and a choice was made to implement it using the CSS properties 'unicode-bidi' and 'direction'. Why do you feel that executeMakeTextDirectionLeftToRight() needs to use DOM attributes, and how does it relate to this bug? 104843 6 hbono 2009-01-07 22:32:38 -0800 > executeMakeTextDirectionLeftToRight() implements functionality that, as far as > I know, does not exist in other engines, and a choice was made to implement it > using the CSS properties 'unicode-bidi' and 'direction'. Why do you feel that > executeMakeTextDirectionLeftToRight() needs to use DOM attributes, and how > does it relate to this bug? Sorry again, I forgot describing it in this thread. (I'm mixed this thread and another internal discussion.) Maybe we are somewhat misunderstanding WebKit, however, we mapped a Right Ctrl + Right Shift key combination to this executeMakeTextDirectionLeftToRight() function in our EditorClientImpl::handleKeyboardEvent() implementation but it did not change the "dir" attribute and caused the original problem. So, I assumed this function should change the "dir" attribute as I wrote in my previous response. If this mapping is wrong, is it possible to give us better mapping functions? (To read the _changeBaseWritingDirectionTo, it seems to call the Editor::setBaseWritingDirection() function. Nevertheless, I'm not sure I'm correct.) 104845 7 mitz 2009-01-07 22:39:49 -0800 (In reply to comment #6) > Sorry again, I forgot describing it in this thread. (I'm mixed this thread and > another internal discussion.) > > Maybe we are somewhat misunderstanding WebKit, however, we mapped a Right Ctrl > + Right Shift key combination to this executeMakeTextDirectionLeftToRight() > function in our EditorClientImpl::handleKeyboardEvent() implementation but it > did not change the "dir" attribute and caused the original problem. > So, I assumed this function should change the "dir" attribute as I wrote in my > previous response. > > If this mapping is wrong, is it possible to give us better mapping functions? > (To read the _changeBaseWritingDirectionTo, it seems to call the > Editor::setBaseWritingDirection() function. Nevertheless, I'm not sure I'm > correct.) Yes, I think the correct mapping for the Ctrl+Shift (or equivalent) actions is to Editor::setBaseWritingDirection(). That function has specific code to set the 'dir' DOM attribute on text entry elements. It is also the function that implements the Writing Direction submenu of the context menu you get when you right-click in a text entry element or in editable HTML. I think Ctrl+Shift should have the same effect as choosing the appropriate item from the context menu, so it follows that it should call in to the same function. 104847 8 hbono 2009-01-07 22:48:24 -0800 > Yes, I think the correct mapping for the Ctrl+Shift (or equivalent) actions is > to Editor::setBaseWritingDirection(). That function has specific code to set > the 'dir' DOM attribute on text entry elements. It is also the function that > implements the Writing Direction submenu of the context menu you get when you > right-click in a text entry element or in editable HTML. I think Ctrl+Shift > should have the same effect as choosing the appropriate item from the context > menu, so it follows that it should call in to the same function. Thank you for your answers and descriptions. Your description makes me notice this is a bug of our implementation of the EditorClientImpl class. Sorry for confusing you. Regards, Hironori Bono 104849 9 xji 2009-01-07 22:54:00 -0800 Hi Mitz, Thanks for your help on solving this issue! After I filed the bug, Jeremy mentioned to me that "From mitz@webkit.org's responses to some of the bugs we've opened recently it looks like in the cases where Windows & OS X diverge, webkit tries to match OSX's behavior.". Now I understand what you meant better. In this case, it is not a Webkit bug. And I am closing it. Thanks, Xiaomei I am closing it. 104850 10 mitz 2009-01-07 23:09:11 -0800 (In reply to comment #9) > Hi Mitz, > > Thanks for your help on solving this issue! > > After I filed the bug, Jeremy mentioned to me that "From mitz@webkit.org's > responses to some of the bugs we've opened recently it looks like in the cases > where Windows & OS X diverge, webkit tries to match OSX's behavior.". That is a good description of the way many things are in WebKit right now, but it is not meant as a guideline. It is not a goal of the WebKit project to introduce Mac OS X-like behaviors on platforms that have different behaviors and conventions. Ideally, WebKit should adopt a behavior that matches the platform, by means of port-specific definitions and code or by means of runtime configuration options. To put it in terms of some of the bugs you may be referring to, it means that it would be wrong to suggest that the Mac OS X port of WebKit should draw an insertion point with a directionality flag, like Windows does sometimes, but it may not be wrong to suggest that the Windows/Cairo port should draw the insertion point like that; or that there should be a WebCore setting for the kind of insertion point to draw. > Now I understand what you meant better. > > In this case, it is not a Webkit bug. And I am closing it. I think this bug has raised at least one valid WebKit issue, which is that the Windows ports need to respond to Ctrl+Shift by changing the writing direction, similarly to how the Mac OS X port changes the writing direction in response to the Mac OS X key combination for the same action. I think this issue should be resolved and I believe the way to resolve it is through a WebKit patch. A bugs.webkit.org bug is a fine way to bring this issue to resolution. You are welcome to either file a new bug or re-open this one, perhaps re-titling it to better reflect the issue. 105175 11 playmobil 2009-01-10 20:05:39 -0800 reopening... 111384 12 28061 hbono 2009-02-26 20:49:50 -0800 Created attachment 28061 a proposed fix (WebKit part) Sorry for my slow responses. Even though this is not a complete fix for this bug (because it is caused by our implementation of the EditorClientImpl class), I needed to add some values to the PlatformKeyboardEvent class so the EditorClientImpl class can distinguish right-modifier keys and left ones. 111403 13 ap 2009-02-27 00:12:31 -0800 What will be the meaning of m_ctrlKey after this change? Will it be left Ctrl key, or any one? In most cases, we don't care which side the key was at. We need to expose right/left information to DOM, see this FIXME in KeyboardEvent.cpp: , m_keyLocation(key.isKeypad() ? DOM_KEY_LOCATION_NUMPAD : DOM_KEY_LOCATION_STANDARD) // FIXME: differentiate right/left, too 111415 14 hbono 2009-02-27 01:13:34 -0800 Thank you for your comments. (In reply to comment #13) > What will be the meaning of m_ctrlKey after this change? Will it be left Ctrl > key, or any one? In most cases, we don't care which side the key was at. To keep compatibility with the current WebKit, I thought 'm_ctrlKey' should represent any control keys. Should we add comments to clarify this? > We need to expose right/left information to DOM, see this FIXME in KeyboardEvent.cpp: > > , m_keyLocation(key.isKeypad() ? DOM_KEY_LOCATION_NUMPAD : DOM_KEY_LOCATION_STANDARD) // FIXME: differentiate right/left, too Thank you for noticing this. I left this class unmodified in my previous change, because I'm wondering which value we should set when we pressed a right modifier key and a left modifier key, e.g. a right-shift key and a left-control key. As far as I read the DOM Event spec, it does not write anything about such edge case. (This is also the reason why my change just adds all right-modifier keys to the PlatformKeyboardEvent class.) (*1) http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-KeyboardEvent Even though I prefer setting DOM_KEY_LOCATION_RIGHT when one of right modifier keys are pressed, I'm not so confident of my opinion at all. Would it be possible to give me your thoughts? 111418 15 ap 2009-02-27 01:38:09 -0800 (In reply to comment #14) > To keep compatibility with the current WebKit, I thought 'm_ctrlKey' should > represent any control keys. Should we add comments to clarify this? Please do, this wasn't clear from the context. > I left this class unmodified in my previous change, because I'm wondering which > value we should set when we pressed a right modifier key and a left modifier > key, e.g. a right-shift key and a left-control key. KeyboardEvent::m_keyLocation contains information about the latest key that was pressed, not on modifiers state, so I don't think that pressing several modifier keys at once changes anything. In practice, it's possible that underlying OS events do not contain all the necessary information (see e.g. a FIXME in KeyEventMac.mm, function isKeyUpEvent()), but we should try to handle common cases. Perhaps the changes to event classes should be made in a separate bug, that this one would depend upon? They are not directly related to LTR text. 111445 16 28061 darin 2009-02-27 09:20:35 -0800 Comment on attachment 28061 a proposed fix (WebKit part) Should tbe right keys be treated as entirely separate from the non-right ones? What about the code already in WebCore that calls shiftKey()? If we really are going to have separate booleans like this, then I think it need to be shiftKey(), leftShiftKey(), and rightShiftKey() functions, with shiftKey() returning m_shiftKey | m_rightShiftKey. Or maybe you intend m_shiftKey to be true if either the left or right key is down? If no platform-independent code is going to be calling these new functions, then I think the Chromium code should match the other platforms and allow you to get to a lower level platform event object. This class is supposed to define a platform-independent interface to keys for use in platform-independent code. If this is an interface defined only for Chromium and used only in Chromium, then I think you should consider doing it differently. But maybe we do have a cross-platform need to distinguish right and left modifiers. I'm not sure. Given the title of the bug it seems that really this is a Chromium-specific bug about needing to set the shift key boolean even when the right shift key is the one held down, and doesn't require any change to the cross-platform code at all, but I really can't tell. If we're going to add booleans for the right-key versions of these modifiers, then the patch needs to also modify the implementation on other platforms so that those new booleans are set on those platforms too. It's bad manners to add these for one platform and have them all be false on all the other platforms. I'm going to say review- for now given these concerns? 111793 17 hbono 2009-03-02 01:01:10 -0800 Thank you for your comments. They make sense, my change is too dependent on Chromium and we should not put such platform-dependent code there. By the way, I'm wondering if there is a plan of fixing the KeyboardEvent class so that it can expose left/right information in near future. If there is a plan, we should wait implementing Chromium-dependent code until the KeyboardEvent class is updated to avoid duplicates. Sorry for my stupid question in advance. (In reply to comment #16) > (From update of attachment 28061 [review]) > Should tbe right keys be treated as entirely separate from the non-right ones? > What about the code already in WebCore that calls shiftKey()? If we really are > going to have separate booleans like this, then I think it need to be > shiftKey(), leftShiftKey(), and rightShiftKey() functions, with shiftKey() > returning m_shiftKey | m_rightShiftKey. Or maybe you intend m_shiftKey to be > true if either the left or right key is down? > > If no platform-independent code is going to be calling these new functions, > then I think the Chromium code should match the other platforms and allow you > to get to a lower level platform event object. This class is supposed to define > a platform-independent interface to keys for use in platform-independent code. > If this is an interface defined only for Chromium and used only in Chromium, > then I think you should consider doing it differently. > > But maybe we do have a cross-platform need to distinguish right and left > modifiers. I'm not sure. Given the title of the bug it seems that really this > is a Chromium-specific bug about needing to set the shift key boolean even when > the right shift key is the one held down, and doesn't require any change to the > cross-platform code at all, but I really can't tell. > > If we're going to add booleans for the right-key versions of these modifiers, > then the patch needs to also modify the implementation on other platforms so > that those new booleans are set on those platforms too. It's bad manners to add > these for one platform and have them all be false on all the other platforms. > > I'm going to say review- for now given these concerns? > 111794 18 playmobil 2009-03-02 01:41:33 -0800 (Just restating a few things to be clear, apologies if this is obvious) This issue relates to the Windows platform in general and is not specific to Chromium. The Windows convention is to use left shift + left control and right shift + right control to toggle writing direction. In addition, according to comment #13 there is a cross-platform use case for differentiating these. Darin/Dan: Seeing as this is not Chromium-only, are you OK with adding leftShiftKey()/rightShiftKey() functions? 28061 2009-02-26 20:49:50 -0800 2010-06-10 16:38:29 -0700 a proposed fix (WebKit part) issue23156-patch1.txt text/plain 3032 hbono SW5kZXg6IFdlYkNvcmUvQ2hhbmdlTG9nCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvQ2hhbmdlTG9n CShyZXZpc2lvbiA0MTI3OCkKKysrIFdlYkNvcmUvQ2hhbmdlTG9nCSh3b3JraW5nIGNvcHkpCkBA IC0xLDMgKzEsMjQgQEAKKzIwMDktMDItMjYgIEhpcm9ub3JpIEJvbm8gIDxoYm9ub0BjaHJvbWl1 bS5vcmc+CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAg aHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTIzMTU2CisKKyAgICAgICAg QWRkZWQgdmFsdWVzIHRvIHRoZSBXZWJDb3JlOjpQbGF0Zm9ybUtleWJvYXJkRXZlbnQgY2xhc3Mg dG8KKyAgICAgICAgZGlzdGluZ3Vpc2ggcmlnaHQgbW9kaWZpZXIga2V5cyBmcm9tIGxlZnQgb25l cy4KKyAgICAgICAgVG8gbm90aWZ5IGEgdXNlciBwcmVzc2VzIHJpZ2h0LXNoaWZ0IGFuZCByaWdo dC1jb250cm9sIGtleXMgdG8KKyAgICAgICAgV2ViS2l0LCB0aGlzIGNoYW5nZSBhZGRzIHNvbWUg bW9kaWZpZXJzIChSaWdodEFsdEtleSwgUmlnaHRDdHJsS2V5LAorICAgICAgICBSaWdodE1ldGFL ZXksIGFuZCBSaWdodFNoaWZ0S2V5KSB0byB0aGUgV2ViQ29yZTo6UGxhdGZvcm1LZXlib2FyZEV2 ZW50CisgICAgICAgIGNsYXNzLgorCisgICAgICAgICogcGxhdGZvcm0vUGxhdGZvcm1LZXlib2Fy ZEV2ZW50Lmg6CisgICAgICAgIChXZWJDb3JlOjpQbGF0Zm9ybUtleWJvYXJkRXZlbnQ6Oik6Cisg ICAgICAgIChXZWJDb3JlOjpQbGF0Zm9ybUtleWJvYXJkRXZlbnQ6OnJpZ2h0U2hpZnRLZXkpOgor ICAgICAgICAoV2ViQ29yZTo6UGxhdGZvcm1LZXlib2FyZEV2ZW50OjpyaWdodEN0cmxLZXkpOgor ICAgICAgICAoV2ViQ29yZTo6UGxhdGZvcm1LZXlib2FyZEV2ZW50OjpyaWdodEFsdEtleSk6Cisg ICAgICAgIChXZWJDb3JlOjpQbGF0Zm9ybUtleWJvYXJkRXZlbnQ6OnJpZ2h0TWV0YUtleSk6Cisg ICAgICAgIChXZWJDb3JlOjpQbGF0Zm9ybUtleWJvYXJkRXZlbnQ6Om1vZGlmaWVycyk6CisKIDIw MDktMDItMjYgIFN0ZXBoZW4gV2hpdGUgIDxzZW5vcmJsYW5jb0BjaHJvbWl1bS5vcmc+CiAKICAg ICAgICAgUmV2aWV3ZWQgYnkgRXJpYyBTZWlkZWwuCkluZGV4OiBXZWJDb3JlL3BsYXRmb3JtL1Bs YXRmb3JtS2V5Ym9hcmRFdmVudC5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvcGxhdGZvcm0vUGxh dGZvcm1LZXlib2FyZEV2ZW50LmgJKHJldmlzaW9uIDQxMjc3KQorKysgV2ViQ29yZS9wbGF0Zm9y bS9QbGF0Zm9ybUtleWJvYXJkRXZlbnQuaAkod29ya2luZyBjb3B5KQpAQCAtODIsNiArODIsMTAg QEAgbmFtZXNwYWNlIFdlYkNvcmUgewogICAgICAgICAgICAgQ3RybEtleSA9IDEgPDwgMSwKICAg ICAgICAgICAgIE1ldGFLZXkgPSAxIDw8IDIsCiAgICAgICAgICAgICBTaGlmdEtleSA9IDEgPDwg MywKKyAgICAgICAgICAgIFJpZ2h0QWx0S2V5ID0gMSA8PCA0LAorICAgICAgICAgICAgUmlnaHRD dHJsS2V5ID0gMSA8PCA1LAorICAgICAgICAgICAgUmlnaHRNZXRhS2V5ID0gMSA8PCA2LAorICAg ICAgICAgICAgUmlnaHRTaGlmdEtleSA9IDEgPDwgNywKICAgICAgICAgfTsKIAogICAgICAgICBU eXBlIHR5cGUoKSBjb25zdCB7IHJldHVybiBtX3R5cGU7IH0KQEAgLTExNiwxMSArMTIwLDE5IEBA IG5hbWVzcGFjZSBXZWJDb3JlIHsKICAgICAgICAgYm9vbCBjdHJsS2V5KCkgY29uc3QgeyByZXR1 cm4gbV9jdHJsS2V5OyB9CiAgICAgICAgIGJvb2wgYWx0S2V5KCkgY29uc3QgeyByZXR1cm4gbV9h bHRLZXk7IH0KICAgICAgICAgYm9vbCBtZXRhS2V5KCkgY29uc3QgeyByZXR1cm4gbV9tZXRhS2V5 OyB9CisgICAgICAgIGJvb2wgcmlnaHRTaGlmdEtleSgpIGNvbnN0IHsgcmV0dXJuIG1fcmlnaHRT aGlmdEtleTsgfQorICAgICAgICBib29sIHJpZ2h0Q3RybEtleSgpIGNvbnN0IHsgcmV0dXJuIG1f cmlnaHRDdHJsS2V5OyB9CisgICAgICAgIGJvb2wgcmlnaHRBbHRLZXkoKSBjb25zdCB7IHJldHVy biBtX3JpZ2h0QWx0S2V5OyB9CisgICAgICAgIGJvb2wgcmlnaHRNZXRhS2V5KCkgY29uc3QgeyBy ZXR1cm4gbV9yaWdodE1ldGFLZXk7IH0KICAgICAgICAgdW5zaWduZWQgbW9kaWZpZXJzKCkgY29u c3QgewogICAgICAgICAgICAgcmV0dXJuIChhbHRLZXkoKSA/IEFsdEtleSA6IDApCiAgICAgICAg ICAgICAgICAgfCAoY3RybEtleSgpID8gQ3RybEtleSA6IDApCiAgICAgICAgICAgICAgICAgfCAo bWV0YUtleSgpID8gTWV0YUtleSA6IDApCi0gICAgICAgICAgICAgICAgfCAoc2hpZnRLZXkoKSA/ IFNoaWZ0S2V5IDogMCk7CisgICAgICAgICAgICAgICAgfCAoc2hpZnRLZXkoKSA/IFNoaWZ0S2V5 IDogMCkKKyAgICAgICAgICAgICAgICB8IChyaWdodEFsdEtleSgpID8gUmlnaHRBbHRLZXkgOiAw KQorICAgICAgICAgICAgICAgIHwgKHJpZ2h0Q3RybEtleSgpID8gUmlnaHRDdHJsS2V5IDogMCkK KyAgICAgICAgICAgICAgICB8IChyaWdodE1ldGFLZXkoKSA/IFJpZ2h0TWV0YUtleSA6IDApCisg ICAgICAgICAgICAgICAgfCAocmlnaHRTaGlmdEtleSgpID8gUmlnaHRTaGlmdEtleSA6IDApOwog ICAgICAgICB9CiAKICAgICAgICAgc3RhdGljIGJvb2wgY3VycmVudENhcHNMb2NrU3RhdGUoKTsK QEAgLTE2NSw2ICsxNzcsMTAgQEAgbmFtZXNwYWNlIFdlYkNvcmUgewogICAgICAgICBib29sIG1f Y3RybEtleTsKICAgICAgICAgYm9vbCBtX2FsdEtleTsKICAgICAgICAgYm9vbCBtX21ldGFLZXk7 CisgICAgICAgIGJvb2wgbV9yaWdodFNoaWZ0S2V5OworICAgICAgICBib29sIG1fcmlnaHRDdHJs S2V5OworICAgICAgICBib29sIG1fcmlnaHRBbHRLZXk7CisgICAgICAgIGJvb2wgbV9yaWdodE1l dGFLZXk7CiAKICNpZiBQTEFURk9STShNQUMpCiAgICAgICAgIFJldGFpblB0cjxOU0V2ZW50PiBt X21hY0V2ZW50Owo=