<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "https://bugs.webkit.org/page.cgi?id=bugzilla.dtd">

<bugzilla version="5.0.4.1"
          urlbase="https://bugs.webkit.org/"
          
          maintainer="admin@webkit.org"
>

    <bug>
          <bug_id>55133</bug_id>
          
          <creation_ts>2011-02-24 04:50:07 -0800</creation_ts>
          <short_desc>An inconsistency between HTMLTextAreaElement::m_value and RenderTextControl::text()</short_desc>
          <delta_ts>2014-04-01 19:00:33 -0700</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>WebKit</product>
          <component>Text</component>
          <version>528+ (Nightly build)</version>
          <rep_platform>PC</rep_platform>
          <op_sys>OS X 10.5</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>INVALID</resolution>
          
          
          <bug_file_loc>http://crbug.com/66848</bug_file_loc>
          <status_whiteboard></status_whiteboard>
          <keywords></keywords>
          <priority>P2</priority>
          <bug_severity>Normal</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          <everconfirmed>0</everconfirmed>
          <reporter name="Kenichi Ishibashi">bashi</reporter>
          <assigned_to name="Nobody">webkit-unassigned</assigned_to>
          <cc>ap</cc>
    
    <cc>ddavidso</cc>
    
    <cc>hamaji</cc>
    
    <cc>jiapu.mail</cc>
    
    <cc>rniwa</cc>
          

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>356886</commentid>
    <comment_count>0</comment_count>
    <who name="Kenichi Ishibashi">bashi</who>
    <bug_when>2011-02-24 04:50:07 -0800</bug_when>
    <thetext>There could be an inconsistency between HTMLTextAreaElement::m_value and RenderTextControl::text() in some cases and it could cause strange bugs.

Suppose a textarea has focus. When a textInput event occur, the text is inserted into m_innerText of the textarea&apos;s renderer (RenderTextControl) by calling InsertTextCommand::input() from TypingCommand::insertTextRunWitoutNewlines(). At this point, m_value of HTMLTextAreaElement is not up-to-date so there is an inconsistency between them until calling setFormControlValueMatchesRenderer(false). The problem arises if style update occurs before calling setFormControlValueMatchesRenderer(false). If updateStyleIfNeeded() is called as a result of style update, RenderTextControlMultiLine::updateFromElement() is called and it sets the up-to-date value of the renderer to the m_value of textarea which is obsoleted. In most cases, style update doesn&apos;t occur before calling setFormControlValueMatchesRenderer(false), but in some cases, it happens.

An chromium bug reported at http://crbug.com/66848 is one of such cases. When textarea has an event listener that is fired by key events and changes its style attribute, updateStyleIfNeeded() could be called while there is the inconsistency. As the result, inputted text doesn&apos;t appear in the textarea. Here is a stack trace of such situation:

#0  WebCore::RenderTextControl::setInnerTextValue (this=0x45b73e8, innerTextValue=&quot;bar&quot;) at third_party/WebKit/Source/WebCore/rendering/RenderTextControl.cpp:183
#1  0x0000000001498c27 in WebCore::RenderTextControlMultiLine::updateFromElement (this=0x45b73e8) at third_party/WebKit/Source/WebCore/rendering/RenderTextControlMultiLine.cpp:107
#2  0x00000000005a3862 in WebCore::updateFromElementCallback (node=0x45b6af0) at third_party/WebKit/Source/WebCore/html/HTMLFormControlElement.cpp:222
#3  0x0000000000f693e0 in WebCore::ContainerNode::dispatchPostAttachCallbacks () at third_party/WebKit/Source/WebCore/dom/ContainerNode.cpp:707
#4  0x0000000000f69272 in WebCore::ContainerNode::resumePostAttachCallbacks (this=0x44d0e20) at third_party/WebKit/Source/WebCore/dom/ContainerNode.cpp:674
#5  0x0000000000f7e428 in WebCore::Document::recalcStyle (this=0x44d0e20, change=WebCore::Node::NoChange) at third_party/WebKit/Source/WebCore/dom/Document.cpp:1542
#6  0x0000000000f7e5d7 in WebCore::Document::updateStyleIfNeeded (this=0x44d0e20) at third_party/WebKit/Source/WebCore/dom/Document.cpp:1565
#7  0x0000000000f7e770 in WebCore::Document::updateLayout (this=0x44d0e20) at third_party/WebKit/Source/WebCore/dom/Document.cpp:1592
#8  0x0000000000f7e8c2 in WebCore::Document::updateLayoutIgnorePendingStylesheets (this=0x44d0e20) at third_party/WebKit/Source/WebCore/dom/Document.cpp:1628
#9  0x000000000107b0a8 in WebCore::VisiblePosition::canonicalPosition (this=0x7fffffffa190, passedPosition=...) at third_party/WebKit/Source/WebCore/editing/VisiblePosition.cpp:459
#10 0x000000000107971b in WebCore::VisiblePosition::init (this=0x7fffffffa190, position=..., affinity=WebCore::DOWNSTREAM) at third_party/WebKit/Source/WebCore/editing/VisiblePosition.cpp:61
#11 0x0000000001079571 in WebCore::VisiblePosition::VisiblePosition (this=0x7fffffffa190, pos=..., affinity=WebCore::DOWNSTREAM) at third_party/WebKit/Source/WebCore/editing/VisiblePosition.cpp:48
#12 0x0000000001076880 in WebCore::TypingCommand::markMisspellingsAfterTyping (this=0x45f2a20, commandType=WebCore::TypingCommand::InsertText) at third_party/WebKit/Source/WebCore/editing/TypingCommand.cpp:322
#13 0x00000000010769b9 in WebCore::TypingCommand::typingAddedToOpenCommand (this=0x45f2a20, commandTypeForAddedTyping=WebCore::TypingCommand::InsertText) at third_party/WebKit/Source/WebCore/editing/TypingCommand.cpp:348
#14 0x0000000001076d3a in WebCore::TypingCommand::insertTextRunWithoutNewlines (this=0x45f2a20, text=&quot;z&quot;, selectInsertedText=false) at third_party/WebKit/Source/WebCore/editing/TypingCommand.cpp:395
#15 0x0000000001076acc in WebCore::TypingCommand::insertText (this=0x45f2a20, text=&quot;z&quot;, selectInsertedText=false) at third_party/WebKit/Source/WebCore/editing/TypingCommand.cpp:369
#16 0x000000000107679b in WebCore::TypingCommand::doApply (this=0x45f2a20) at third_party/WebKit/Source/WebCore/editing/TypingCommand.cpp:293
#17 0x00000000010303e9 in WebCore::EditCommand::apply (this=0x45f2a20) at third_party/WebKit/Source/WebCore/editing/EditCommand.cpp:92
#18 0x0000000001030a4a in WebCore::applyCommand (command=...) at third_party/WebKit/Source/WebCore/editing/EditCommand.cpp:214
#19 0x00000000010760b6 in WebCore::TypingCommand::insertText (document=0x44d0e20, text=&quot;z&quot;, selectionForInsertion=..., selectInsertedText=false, compositionType=WebCore::TypingCommand::TextCompositionNone) at third_party/WebKit/Source/WebCore/editing/TypingCommand.cpp:198
(snip)

Basically, this problem can avoid calling setFormControlValueMatchesRenderer(false) immediately after updating text value of the renderer. IMHO, calling appliedEditing() just after calling InsertTextCommand::input() is the simplest way to do it, as Safari on SnowLoepard do. However, as the comments on https://bugs.webkit.org/show_bug.cgi?id=49523 describe, it somehow complicated.

I didn&apos;t investigated in detail, but I think this is the primary cause of bug 49523 and 46868.

I&apos;d like to fix the problem by removing PLATFORM(MAC) from TypingCommand::typingAddedToOpenCommand() because I think it is simple and natural way to resolve the inconsistency. However, I&apos;m not familiar with the code, I&apos;d like to ask advice.

Thanks,</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>356892</commentid>
    <comment_count>1</comment_count>
      <attachid>83636</attachid>
    <who name="Kenichi Ishibashi">bashi</who>
    <bug_when>2011-02-24 04:55:54 -0800</bug_when>
    <thetext>Created attachment 83636
A page to repro

To see the problem, type some characters in the textarea. Note that the problem could happen on Chromium and will not happen on Safari.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>357597</commentid>
    <comment_count>2</comment_count>
      <attachid>83754</attachid>
    <who name="Kenichi Ishibashi">bashi</who>
    <bug_when>2011-02-24 17:39:09 -0800</bug_when>
    <thetext>Created attachment 83754
workaround patch for http://crbug.com/66848</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>357601</commentid>
    <comment_count>3</comment_count>
    <who name="Kenichi Ishibashi">bashi</who>
    <bug_when>2011-02-24 17:49:41 -0800</bug_when>
    <thetext>(In reply to comment #2)
&gt; Created an attachment (id=83754) [details]
&gt; workaround patch for http://crbug.com/66848

This is workaround patch to fix http://crbug.com/66848 without removing PLATFORM(MAC) macro. spellcheckAttributeState() is called from typingAddedToOpenCommand() and hasAttribute() and getAttribute() eventually call updateStyleAttribute(), which causes calling updateStyleIfNeeded(). We can avoid this using fastHasAttribute()/fastGetAttribute() because they don&apos;t call updateStyleAttribute(). If removing PLATFORM(MAC) is not good for fixing the problem, I&apos;d like to land this patch.</thetext>
  </long_desc>
      
          <attachment
              isobsolete="0"
              ispatch="0"
              isprivate="0"
          >
            <attachid>83636</attachid>
            <date>2011-02-24 04:55:54 -0800</date>
            <delta_ts>2011-02-24 04:55:54 -0800</delta_ts>
            <desc>A page to repro</desc>
            <filename>repro.html</filename>
            <type>text/html</type>
            <size>1078</size>
            <attacher name="Kenichi Ishibashi">bashi</attacher>
            
              <data encoding="base64">PGh0bWw+CjxzdHlsZT4KICAvKiBUaGlzIHJ1bGUgY2F1c2VzIGNhbGxpbmcgc2V0TmVlZHNTdHls
ZVJlY2FsYygpIGF0IEVsZW1lbnQ6OnJlY2FsY1N0eWxlSWZOZWVkZWRBZnRlckF0dHJpYnV0ZUNo
YW5nZWQoKSBkdXJpbmcgaGFuZGxpbmcgdGhlIGV2ZW50IGxpc3RlbmVyICovCiAgYm9keVtzdHls
ZV0ge30KPC9zdHlsZT4KCjxzY3JpcHQ+CiAgZnVuY3Rpb24gdXBkYXRlKGUpIHsKICAgIGRvY3Vt
ZW50LmdldEVsZW1lbnRCeUlkKCd0YXJnZXQnKS5zdHlsZS53aWR0aCA9ICcxMDBweCc7CiAgfQog
IGZ1bmN0aW9uIGRvVGVzdCgpIHsKICAgIGlmICh3aW5kb3cubGF5b3V0VGVzdENvbnRyb2xsZXIp
IHsKICAgICAgbGF5b3V0VGVzdENvbnRyb2xsZXIuZHVtcEFzVGV4dCgpOwogICAgICBsYXlvdXRU
ZXN0Q29udHJvbGxlci53YWl0VW50aWxEb25lKCk7CiAgICB9CiAgICB2YXIgdGFyZ2V0ID0gZG9j
dW1lbnQuZ2V0RWxlbWVudEJ5SWQoJ3RhcmdldCcpOwogICAgdGFyZ2V0LmFkZEV2ZW50TGlzdGVu
ZXIoJ3RleHRJbnB1dCcsIHVwZGF0ZSk7CiAgICB0YXJnZXQuZm9jdXMoKTsKICAgIGlmICh3aW5k
b3cuZXZlbnRTZW5kZXIpIHsKICAgICAgZXZlbnRTZW5kZXIua2V5RG93bigneicpOwogICAgICBz
ZXRUaW1lb3V0KGZ1bmN0aW9uKCkgewogICAgICAgIHZhciByZXN1bHQgPSBkb2N1bWVudC5nZXRF
bGVtZW50QnlJZCgncmVzdWx0Jyk7CiAgICAgICAgY29uc29sZS5sb2codGFyZ2V0LnZhbHVlKTsK
ICAgICAgICBpZiAodGFyZ2V0LnZhbHVlID09ICd6YmFyJykKICAgICAgICAgIGRvY3VtZW50Lmdl
dEVsZW1lbnRCeUlkKCdyZXN1bHQnKS5pbm5lckhUTUwgKz0gJ1BBU1MnOwogICAgICAgIGVsc2UK
ICAgICAgICAgIGRvY3VtZW50LmdldEVsZW1lbnRCeUlkKCdyZXN1bHQnKS5pbm5lckhUTUwgKz0g
J0ZBSUwnOwogICAgICAgIGxheW91dFRlc3RDb250cm9sbGVyLm5vdGlmeURvbmUoKTsKICAgICAg
IH0sIDApOwogICAgfQogIH0KPC9zY3JpcHQ+Cgo8Ym9keSBvbmxvYWQ9ImRvVGVzdCgpIj4KICA8
dGV4dGFyZWEgaWQ9InRhcmdldCI+YmFyPC90ZXh0YXJlYT4KPC9ib2R5Pgo8L2h0bWw+Cg==
</data>

          </attachment>
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>83754</attachid>
            <date>2011-02-24 17:39:09 -0800</date>
            <delta_ts>2011-02-24 17:39:09 -0800</delta_ts>
            <desc>workaround patch for http://crbug.com/66848</desc>
            <filename>bug-55133-20110225103907.patch</filename>
            <type>text/plain</type>
            <size>1577</size>
            <attacher name="Kenichi Ishibashi">bashi</attacher>
            
              <data encoding="base64">U3VidmVyc2lvbiBSZXZpc2lvbjogNzk2MzIKZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJDb3JlL0No
YW5nZUxvZyBiL1NvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZwppbmRleCAwYTYzZDMxYzRlMDQ0MDJl
MzljYTJkMjJjMjZmZWNiNTU0ZWI0MmZmLi45NDUzZTBkOTg1YTk3OWMzOTRiNWQ2ZGUzMGYyNTM4
M2NiYjlhZjE2IDEwMDY0NAotLS0gYS9Tb3VyY2UvV2ViQ29yZS9DaGFuZ2VMb2cKKysrIGIvU291
cmNlL1dlYkNvcmUvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMTUgQEAKKzIwMTEtMDItMjQgIEtlbmlj
aGkgSXNoaWJhc2hpICA8YmFzaGlAY2hyb21pdW0ub3JnPgorCisgICAgICAgIFJldmlld2VkIGJ5
IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgIEFuIGluY29uc2lzdGVuY3kgYmV0d2VlbiBIVE1M
VGV4dEFyZWFFbGVtZW50OjptX3ZhbHVlIGFuZCBSZW5kZXJUZXh0Q29udHJvbDo6dGV4dCgpCisg
ICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD01NTEzMworCisg
ICAgICAgIE5vIG5ldyB0ZXN0cy4gKE9PUFMhKQorCisgICAgICAgICogZG9tL0VsZW1lbnQuY3Bw
OgorICAgICAgICAoV2ViQ29yZTo6RWxlbWVudDo6c3BlbGxjaGVja0F0dHJpYnV0ZVN0YXRlKToK
KwogMjAxMS0wMi0yNCAgRGFuIEJlcm5zdGVpbiAgPG1pdHpAYXBwbGUuY29tPgogCiAgICAgICAg
IFJldmlld2VkIGJ5IERhdmUgSHlhdHQuCmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViQ29yZS9kb20v
RWxlbWVudC5jcHAgYi9Tb3VyY2UvV2ViQ29yZS9kb20vRWxlbWVudC5jcHAKaW5kZXggZThkOWY1
OGIwY2IzYTEyNTZkMDAyZGIwNDJkNTdjNjU1ODZjY2Y4ZS4uYmY3ZjY0NjRmNjVjMDNhZTk0Y2Yx
Mjk2M2NmZDRjNTJlNDU4NDBlNiAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvZG9tL0VsZW1l
bnQuY3BwCisrKyBiL1NvdXJjZS9XZWJDb3JlL2RvbS9FbGVtZW50LmNwcApAQCAtMTgzOCwxMCAr
MTgzOCwxMCBAQCB2b2lkIEVsZW1lbnQ6OndlYmtpdFJlcXVlc3RGdWxsU2NyZWVuKHVuc2lnbmVk
IHNob3J0IGZsYWdzKQogCiBTcGVsbGNoZWNrQXR0cmlidXRlU3RhdGUgRWxlbWVudDo6c3BlbGxj
aGVja0F0dHJpYnV0ZVN0YXRlKCkgY29uc3QKIHsKLSAgICBpZiAoIWhhc0F0dHJpYnV0ZShIVE1M
TmFtZXM6OnNwZWxsY2hlY2tBdHRyKSkKKyAgICBpZiAoIWZhc3RIYXNBdHRyaWJ1dGUoSFRNTE5h
bWVzOjpzcGVsbGNoZWNrQXR0cikpCiAgICAgICAgIHJldHVybiBTcGVsbGNoZWNrQXR0cmlidXRl
RGVmYXVsdDsKIAotICAgIGNvbnN0IEF0b21pY1N0cmluZyYgdmFsdWUgPSBnZXRBdHRyaWJ1dGUo
SFRNTE5hbWVzOjpzcGVsbGNoZWNrQXR0cik7CisgICAgY29uc3QgQXRvbWljU3RyaW5nJiB2YWx1
ZSA9IGZhc3RHZXRBdHRyaWJ1dGUoSFRNTE5hbWVzOjpzcGVsbGNoZWNrQXR0cik7CiAgICAgaWYg
KGVxdWFsSWdub3JpbmdDYXNlKHZhbHVlLCAidHJ1ZSIpIHx8IGVxdWFsSWdub3JpbmdDYXNlKHZh
bHVlLCAiIikpCiAgICAgICAgIHJldHVybiBTcGVsbGNoZWNrQXR0cmlidXRlVHJ1ZTsKICAgICBp
ZiAoZXF1YWxJZ25vcmluZ0Nhc2UodmFsdWUsICJmYWxzZSIpKQo=
</data>

          </attachment>
      

    </bug>

</bugzilla>