<?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>53787</bug_id>
          
          <creation_ts>2011-02-04 10:20:00 -0800</creation_ts>
          <short_desc>REGRESSION: Caret is rendered at wrong location when editable region ends with a non-editable region</short_desc>
          <delta_ts>2014-05-09 00:54:03 -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>HTML Editing</component>
          <version>528+ (Nightly build)</version>
          <rep_platform>All</rep_platform>
          <op_sys>All</op_sys>
          <bug_status>NEW</bug_status>
          <resolution></resolution>
          
          
          <bug_file_loc></bug_file_loc>
          <status_whiteboard></status_whiteboard>
          <keywords></keywords>
          <priority>P2</priority>
          <bug_severity>Normal</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          <everconfirmed>1</everconfirmed>
          <reporter name="Ryosuke Niwa">rniwa</reporter>
          <assigned_to name="Nobody">webkit-unassigned</assigned_to>
          <cc>enrica</cc>
    
    <cc>garryb</cc>
    
    <cc>jparent</cc>
    
    <cc>kalman</cc>
    
    <cc>leviw</cc>
    
    <cc>pkoszulinski</cc>
          

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>345586</commentid>
    <comment_count>0</comment_count>
    <who name="Ryosuke Niwa">rniwa</who>
    <bug_when>2011-02-04 10:20:00 -0800</bug_when>
    <thetext>In the following markup,
&lt;div contenteditable&gt;text text&lt;span contenteditable=&quot;false&quot;&gt;foo&lt;/span&gt;&lt;/div&gt;

Clicking a position right after foo results in the caret rendered at the right upper corner instead of at the end of foo.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>345588</commentid>
    <comment_count>1</comment_count>
    <who name="Ryosuke Niwa">rniwa</who>
    <bug_when>2011-02-04 10:20:12 -0800</bug_when>
    <thetext>http://crbug.com/71598</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>345659</commentid>
    <comment_count>2</comment_count>
    <who name="Levi Weintraub">leviw</who>
    <bug_when>2011-02-04 11:54:03 -0800</bug_when>
    <thetext>This unfortunate bug is non-trivial to solve. Editing creates canonical positions that are eventually sent to Render____::localCaretRect to have the rect determined. In certain cases like this, the canonical position editing would *normally* create, [&quot;foo&quot;, 3], doesn&apos;t work (in this case because it&apos;s in non-editable content). There are 2 problems with this:

1) RenderBlock uses RenderBox to determine the caret rect, but for RenderBox, any offset &gt; 0 equates to drawing the caret after the content, even if it&apos;s an offset between children.
2) A RenderBlock and offset isn&apos;t enough information to determine the correct position for the caret. [DIV, 2] in this case could be interpreted to the position after &quot;foo&quot; or the position after the DIV! I think localCaretRect needs to take a type (offset into children, or position before/after renderer e.g. Position::AnchorType).</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>349196</commentid>
    <comment_count>3</comment_count>
      <attachid>82009</attachid>
    <who name="Garry Boyer">garryb</who>
    <bug_when>2011-02-10 11:03:09 -0800</bug_when>
    <thetext>Created attachment 82009
This demonstrates the issue and a couple other cursoring bugs in this use case, but only one of them is a regression (the one tracked on this bug).</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>349197</commentid>
    <comment_count>4</comment_count>
    <who name="Garry Boyer">garryb</who>
    <bug_when>2011-02-10 11:04:08 -0800</bug_when>
    <thetext>Also wanted to emphasize that this issue didn&apos;t exist earlier, it was a regression from Chrome 8 to Chrome 9.  Maybe there were some hacks in earlier versions that fixed this.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>351738</commentid>
    <comment_count>5</comment_count>
    <who name="Levi Weintraub">leviw</who>
    <bug_when>2011-02-15 16:56:39 -0800</bug_when>
    <thetext>The bug where a line break is inserted when backspacing the whitespace following a button is similarly related to legacy positions. DeleteSelectionCommand uses mergeParagraph to handle selections that span paragraph boundaries, and because it upstreams the resulting position after the deletion into [button, 1], the code falsely believes the position to be inside the inline-block element and inserts a placeholder.

The &quot;right&quot; fix for this would be to make Position::upstream() return a position at [button, PositionIsAfterAnchor] and have DeleteSelectionCommand then correctly handle positions after Inline-Block flow elements (where positions before/after treat them like inline nodes and positions inside them like blocks).</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1007922</commentid>
    <comment_count>6</comment_count>
    <who name="Piotrek Koszuliński (Reinmar)">pkoszulinski</who>
    <bug_when>2014-05-09 00:54:03 -0700</bug_when>
    <thetext>The issue was also reported on CKEditor&apos;s bug tracker: http://dev.ckeditor.com/ticket/11923</thetext>
  </long_desc>
      
          <attachment
              isobsolete="0"
              ispatch="0"
              isprivate="0"
          >
            <attachid>82009</attachid>
            <date>2011-02-10 11:03:09 -0800</date>
            <delta_ts>2011-02-10 11:03:09 -0800</delta_ts>
            <desc>This demonstrates the issue and a couple other cursoring bugs in this use case, but only one of them is a regression (the one tracked on this bug).</desc>
            <filename>webkitbug.html</filename>
            <type>text/html</type>
            <size>2553</size>
            <attacher name="Garry Boyer">garryb</attacher>
            
              <data encoding="base64">PCFET0NUWVBFIGh0bWw+CjxodG1sPgo8aGVhZD4KICA8dGl0bGU+RWRpdGFibGUgVGVzdDwvdGl0
bGU+CiAgPHN0eWxlPgogICAgYm9keSB7CiAgICAgIGZvbnQ6IDEzcHggQXJpYWwsIHNhbnMtc2Vy
aWY7CiAgICB9CiAgICAuZWRpdGJveCB7CiAgICAgIGJvcmRlcjogMXB4IHNvbGlkIGJsYWNrOwog
ICAgICBwYWRkaW5nOiAxMHB4OwogICAgICB3aWR0aDogNDAwcHg7CiAgICB9CiAgICAucGlsbDIg
ewogICAgICBkaXNwbGF5OiBpbmxpbmUtYmxvY2s7CgogICAgICBiYWNrZ3JvdW5kOiAjMDA5Owog
ICAgICBib3JkZXI6IG5vbmU7CiAgICAgIGJvcmRlci1yYWRpdXM6IDNweDsKICAgICAgLW1vei1i
b3JkZXItcmFkaXVzOiAzcHg7CiAgICAgIC13ZWJraXQtYm9yZGVyLXJhZGl1czogM3B4OwogICAg
ICBjb2xvcjogI2ZmZjsKICAgICAgZm9udDogbm9ybWFsIDEzcHggQXJpYWwsIHNhbnMtc2VyaWY7
CiAgICAgIG1hcmdpbjogMCAycHg7CiAgICAgIHBhZGRpbmc6IDFweCAycHg7CiAgICB9CiAgPC9z
dHlsZT4KPC9oZWFkPgo8Ym9keT4KICA8cD5CYWNrZ3JvdW5kOiBJIGp1c3Qgd2FudCBhbiBlbGVt
ZW50IHRoYXQgY2FuIGNvbnRhaW4gdGV4dCBhbmQgYmVoYXZlcyBhdG9taWNhbGx5IChsaWtlIGFu
IGltYWdlKS48L3A+CiAgPGgzPkNocm9tZSA5IHJlZ3Jlc3Npb248L2gyPgogIDxkaXYgY2xhc3M9
ImVkaXRib3giPgogICAgPGRpdiBjb250ZW50RWRpdGFibGU9InRydWUiPgogICAgICBDbGljayBy
aWdodCBhZnRlciB0aGUgYnV0dG9uLiAgVGhlIGN1cnNvciBpcyBmaW5lIGluIENocm9tZSA4IGJ1
dCBpcyBkaXNwbGF5ZWQgYXQgdGhlIHVwcGVyIHJpZ2h0IGNvcm5lciBvZiB0aGUgY29udGVudEVk
aXRhYmxlIGluIENocm9tZSA5LiA8YnV0dG9uIGNsYXNzPSJwaWxsMiIgdGFiSW5kZXg9Ii0xIiBj
b250ZW50RWRpdGFibGU9ImZhbHNlIj5idXR0b24gbm9uLWVkaXRhYmxlPC9idXR0b24+PC9kaXY+
CiAgPC9kaXY+CiAgPGgzPkRvZXNuJ3QgaGFwcGVuIHdoZW4gdGhlIGVsZW1lbnQgaXMgZWRpdGFi
bGU8L2gzPgogIDxkaXYgY2xhc3M9ImVkaXRib3giPgogICAgPGRpdiBjb250ZW50RWRpdGFibGU9
InRydWUiPgogICAgICBUaGlzIGJ1dHRvbiBkb2VzIG5vdCBoYXZlIGNvbnRlbnRFZGl0YWJsZT1m
YWxzZSwgYW5kIGRvZXMgbm90IGhhdmUgdGhlIGlzc3VlLiA8YnV0dG9uIGNsYXNzPSJwaWxsMiIg
dGFiSW5kZXg9Ii0xIj5idXR0b24gZWRpdGFibGU8L2J1dHRvbj4KICAgIDwvZGl2PgogIDwvZGl2
PgogIDxoMz5JdCdzIG5vdCBqdXN0ICZsdDtidXR0b24mZ3Q7czwvaDM+CiAgPGRpdiBjbGFzcz0i
ZWRpdGJveCI+CiAgICA8ZGl2IGNvbnRlbnRFZGl0YWJsZT0idHJ1ZSI+CiAgICAgIFRoaXMgaXMg
YSBzcGFuLiA8c3BhbiBjbGFzcz0icGlsbDIiIHRhYkluZGV4PSItMSIgY29udGVudEVkaXRhYmxl
PSJmYWxzZSI+c3BhbiBub24tZWRpdGFibGU8L3NwYW4+CiAgICA8L2Rpdj4KICA8L2Rpdj4KCiAg
PGhyIHN0eWxlPSJtYXJnaW4tdG9wOiA1ZW0iPgogIDxoMj5TZXBhcmF0ZSBidWcgdGhhdCBtaWdo
dCBiZSByZWxhdGVkIC0gcmVwcm9lcyBvbiBDaHJvbWUgOCAoYW5kIHByb2JhYmx5IGVhcmxpZXIp
IDwvaDI+CiAgPGRpdiBjbGFzcz0iZWRpdGJveCI+CiAgICA8ZGl2IGNvbnRlbnRFZGl0YWJsZT0i
dHJ1ZSI+CiAgICAgIERlbGV0ZSB0aGUgc3BhY2UgYWZ0ZXIgdGhpcyBidXR0b246IDxidXR0b24g
Y2xhc3M9InBpbGwyIiB0YWJJbmRleD0iLTEiPmJ1dHRvbiBlZGl0YWJsZTwvYnV0dG9uPiAmbHQ7
LS0gZGVsZXRlIHRoZSBzcGFjZSwgYW5kIGEgbmV3bGluZSBpcyBhZGRlZC4KICAgIDwvZGl2Pgog
IDwvZGl2PgogIDxoMz5TZXR0aW5nIGNvbnRlbnRFZGl0YWJsZT1mYWxzZSBhdm9pZHMgdGhhdCBp
c3N1ZTwvaDM+CiAgPGRpdiBjbGFzcz0iZWRpdGJveCI+CiAgICA8ZGl2IGNvbnRlbnRFZGl0YWJs
ZT0idHJ1ZSI+CiAgICAgIE5vdyBpdCB3b3Jrcy4gPGJ1dHRvbiBjbGFzcz0icGlsbDIiIHRhYklu
ZGV4PSItMSIgY29udGVudEVkaXRhYmxlPSJmYWxzZSI+YnV0dG9uIG5vbi1lZGl0YWJsZTwvYnV0
dG9uPiAmbHQ7LS0gZGVsZXRlIHRoZSBzcGFjZSwgYW5kIE5PIG5ld2xpbmUgaXMgYWRkZWQuCiAg
ICA8L2Rpdj4KICA8L2Rpdj4KCiAgPGhyIHN0eWxlPSJtYXJnaW4tdG9wOiA1ZW0iPgogIDxoMj5D
YW5ub3QgY3Vyc29yIHRvIG5vbi1lZGl0YWJsZSBlbGVtZW50IGF0IHRoZSBiZWdpbm5pbmcgb2Yg
YSBsaW5lPC9oMj4KICA8ZGl2IGNsYXNzPSJlZGl0Ym94Ij4KICAgIDxkaXYgY29udGVudEVkaXRh
YmxlPSJ0cnVlIj4KICAgICAgVHJ5IGN1cnNvcmluZyB0byB0aGUgYmVnaW5uaW5nIG9mIHRoZSBm
b2xsb3dpbmcgYnV0dG9uCiAgICAgIDxicj48YnV0dG9uIGNsYXNzPSJwaWxsMiIgdGFiSW5kZXg9
Ii0xIiBjb250ZW50RWRpdGFibGU9ImZhbHNlIj5idXR0b24gbm9uLWVkaXRhYmxlPC9idXR0b24+
ICZsdDstLSBjdXJzb3IgdG8gdGhlIGxlZnQgYW5kIHlvdSBjYW4ndCBjdXJzb3IgYmVmb3JlIHRo
ZSBidXR0b24uCiAgICA8L2Rpdj4KICA8L2Rpdj4KPC9ib2R5Pgo8aHRtbD4K
</data>

          </attachment>
      

    </bug>

</bugzilla>