47806 2010-10-18 03:03:45 -0700 Text inserted at the collapsed selection between two BRs following a non-wrapping text that forces overflow 2022-05-23 09:48:26 -0700 1 1 1 Unclassified WebKit Layout and Rendering 528+ (Nightly build) All All RESOLVED FIXED http://marijn.haverbeke.nl/webkit_scrollbug.html HasReduction P2 Normal --- 1 marijnh+webkit webkit-unassigned almaza24map ampva300 ap cyrusssslim darin enrica eric hyatt jamesr jen123cruz123 leviw mitz ojan richardsfowler3 rniwa tony wdm oldest_to_newest 295414 0 marijnh+webkit 2010-10-18 03:03:45 -0700 The URL I linked shows the problem more precisely, but basically, if you have - A designMode document - A line in this document that's wider than the window, not wrapping, and that's causing a horizontal scrollbar - A double BR afer that line - The cursor sitting on the blank line produced by those BRs ... then you can not type anything. Regular keyboard input seems to be ignored. Moving to another line still works, as does enter (kind of). I'm seeing this in current versions of both Safari and Chrome, on both Linux and Windows. The issue came up because people had trouble using CodeMirror (http://codemirror.net), which creates such BR-filled documents in editable frames. 304347 1 rniwa 2010-11-03 16:36:31 -0700 *** This bug has been marked as a duplicate of bug 23474 *** 304506 2 marijnh+webkit 2010-11-04 00:03:20 -0700 Hold on. This is not a duplicate of bug 23474 at all. I submitted both, so I should know. They manifest themselves in completely different forms. Could someone please either explain how they are the same? 304511 3 72912 rniwa 2010-11-04 00:20:06 -0700 Created attachment 72912 demo (In reply to comment #2) > Hold on. This is not a duplicate of bug 23474 at all. I submitted both, so I should know. They manifest themselves in completely different forms. Could someone please either explain how they are the same? Ugh... sorry about that. That was a mistake. I think I got confused when I was back&forth between two bugs and thought they were the same bug. Clearly, this one is different from the bug 23474. I'll attach a demo so that we don't make the same mistake in the future. 304969 4 leviw 2010-11-04 16:06:52 -0700 The text actually gets inserted into the DOM, but not rendered. Entering text in the same position then smashes the previous contents and replaces it with the new text. Continuing to evaluate... 305031 5 leviw 2010-11-04 17:30:27 -0700 This seems to be a layout problem. The PRE RenderBlock has three InlineFlowBoxes associated with it, as one would expect, however the second InlineFlowBox contains only the BR that follows the "PASS" text node. The PASS node then gets skipped over in the rendering code despite having a renderer. 305037 6 rniwa 2010-11-04 17:35:16 -0700 +dhyatt, mitz, & darin since this is a rendering issue. 305059 7 73019 rniwa 2010-11-04 17:59:50 -0700 Created attachment 73019 demo without editing command It turned out that this is nothing to do with contenteditable. I can reproduce the problem without execCommand / designmode="on". However, we do need to have the selection set at the location we're inserting the text node. 305510 8 73115 leviw 2010-11-05 14:05:57 -0700 Created attachment 73115 Test case using a timeout It turns out selection isn't the culprit! Setting the selection delays the DOM modification until after the first layout, which is the fail case. RenderBlock::layoutInlineChildren does the proper thing when presented with the final DOM on a "full layout" which occurs on the first layout, but subsequent layouts ignore the second InlineFlowBox, perhaps because it's not reporting that it's dirty? Adding a test case that uses a timeout instead of setting selection. 305542 9 jamesr 2010-11-05 14:51:04 -0700 After the page has stabilized the <pre> has three RenderText children: RenderBlock 0x7fffeaaad018 PRE 0x7fffeaaaed80 STYLE=width: 35ex; height: 10em; overflow: scroll; RenderText 0x7fffeaaaec98 #text 0x7fffeaa95720 "You should see 'PASS' below: ----------" RenderBR 0x7ffff7ed91c8 BR 0x7fffeaaaec00 RenderText 0x7fffeb5bfb98 #text 0x7fffeb5a17e0 "hello" RenderBR 0x7ffff7ed9138 BR 0x7fffeaaaeb80 RenderText 0x7fffeaaaeb18 #text 0x7fffeaa956c0 " \n" that correspond to three inline boxes in its linebox list: $26 = {<WebCore::InlineBox> = {_vptr.InlineBox = 0x3cae730, m_next = 0x0, m_prev = 0x0, m_parent = 0x0, m_renderer = 0x7fffeaaad018, m_x = 0, m_y = 0, m_logicalWidth = 312, m_firstLine = true, m_constructed = true, m_bidiEmbeddingLevel = 0 '\000', m_dirty = false, m_extracted = false, m_hasVirtualLogicalHeight = false, m_isHorizontal = true, m_endsWithBreak = false, m_hasSelectedChildren = false, m_hasEllipsisBoxOrHyphen = false, m_dirOverride = false, m_isText = false, m_determinedIfNextOnLineExists = false, m_determinedIfPrevOnLineExists = false, m_nextOnLineExists = false, m_prevOnLineExists = false, m_toAdd = 0, m_hasBadParent = false}, m_overflow = {<WTFNoncopyable::Noncopyable> = {<WTF::FastAllocBase> = {<No data fields>}, <No data fields>}, m_ptr = 0x0}, m_firstChild = 0x7fffeaa3d248, m_lastChild = 0x7fffeaa3d248, m_prevLineBox = 0x0, m_nextLineBox = 0x7fffeb5ef318, m_includeLogicalLeftEdge = false, m_includeLogicalRightEdge = false, m_hasTextChildren = true, m_hasBadChildList = false} (gdb) p *$.m_nextLineBox $27 = {<WebCore::InlineBox> = {_vptr.InlineBox = 0x3cae730, m_next = 0x0, m_prev = 0x0, m_parent = 0x0, m_renderer = 0x7fffeaaad018, m_x = 0, m_y = 16, m_logicalWidth = 0, m_firstLine = false, m_constructed = true, m_bidiEmbeddingLevel = 0 '\000', m_dirty = false, m_extracted = false, m_hasVirtualLogicalHeight = false, m_isHorizontal = true, m_endsWithBreak = true, m_hasSelectedChildren = false, m_hasEllipsisBoxOrHyphen = false, m_dirOverride = false, m_isText = false, m_determinedIfNextOnLineExists = false, m_determinedIfPrevOnLineExists = false, m_nextOnLineExists = false, m_prevOnLineExists = false, m_toAdd = 0, m_hasBadParent = false}, m_overflow = {<WTFNoncopyable::Noncopyable> = {<WTF::FastAllocBase> = {<No data fields>}, <No data fields>}, m_ptr = 0x0}, m_firstChild = 0x7fffeaa3d1d8, m_lastChild = 0x7fffeaa3d1d8, m_prevLineBox = 0x7fffeb5ef3d8, m_nextLineBox = 0x7fffeb5ef258, m_includeLogicalLeftEdge = false, m_includeLogicalRightEdge = false, m_hasTextChildren = true, m_hasBadChildList = false} (gdb) p *$.m_nextLineBox $28 = {<WebCore::InlineBox> = {_vptr.InlineBox = 0x3cae730, m_next = 0x0, m_prev = 0x0, m_parent = 0x0, m_renderer = 0x7fffeaaad018, m_x = 0, m_y = 32, m_logicalWidth = 8, m_firstLine = false, m_constructed = true, m_bidiEmbeddingLevel = 0 '\000', m_dirty = false, m_extracted = false, m_hasVirtualLogicalHeight = false, m_isHorizontal = true, m_endsWithBreak = true, m_hasSelectedChildren = false, m_hasEllipsisBoxOrHyphen = false, m_dirOverride = false, m_isText = false, m_determinedIfNextOnLineExists = false, m_determinedIfPrevOnLineExists = false, m_nextOnLineExists = false, m_prevOnLineExists = false, m_toAdd = 0, m_hasBadParent = false}, m_overflow = {<WTFNoncopyable::Noncopyable> = {<WTF::FastAllocBase> = {<No data fields>}, <No data fields>}, m_ptr = 0x0}, m_firstChild = 0x7fffeaa3d168, m_lastChild = 0x7fffe6dfea28, m_prevLineBox = 0x7fffeb5ef318, m_nextLineBox = 0x0, m_includeLogicalLeftEdge = false, m_includeLogicalRightEdge = false, m_hasTextChildren = true, m_hasBadChildList = false} I'm not sure why the second line box has a m_logicalWidth of 0. If I load up a similar page with the same contents as static HTML rather than dynamically created the second linebox has a m_logicalWidth of 40 which seems like a much more reasonable value. I don't know enough about the line breaker to debug much more usefully. 305688 10 73154 jamesr 2010-11-05 18:21:18 -0700 Created attachment 73154 reduced slightly more Reduced it a bit more. This doesn't appear to be a recent regression, based on testing a few old builds. It does seem like pretty bad behavior, though. 383040 11 ojan 2011-04-10 23:29:07 -0700 The demo and the reduced test case seem to work in chrome 12.0.725.0 (Official Build 80304) dev at webkit revision 82765 (as in, they print out PASS). So, this bug just needs to be converted into a layout test, unless this is already covered by existing tests. Ryosuke, do you know? 383266 12 rniwa 2011-04-11 10:45:54 -0700 (In reply to comment #11) > So, this bug just needs to be converted into a layout test, unless this is already covered by existing tests. Ryosuke, do you know? I think we can just check in jamesr's test case. Sadly, this test needs to be a render tree dump. 383290 13 89033 rniwa 2011-04-11 11:14:34 -0700 Created attachment 89033 adds a regression test 383444 14 rniwa 2011-04-11 13:38:21 -0700 Committed r83487: <http://trac.webkit.org/changeset/83487> 72912 2010-11-04 00:20:06 -0700 2010-11-04 17:59:50 -0700 demo wide.html text/html 385 rniwa PCFET0NUWVBFIGh0bWw+CjxodG1sPgo8aGVhZD4KPC9oZWFkPgo8Ym9keT4KPHByZSBpZD0idGVz dCIgc3R5bGU9IndpZHRoOiAzNWV4OyBoZWlnaHQ6IDEwZW07IG92ZXJmbG93OiBzY3JvbGw7Ij4K WW91IHNob3VsZCBzZWUgJ1BBU1MnIGJlbG93OiAtLS0tLS0tLS0tPGJyPjxicj4KPC9wcmU+Cjxz Y3JpcHQ+Cgpkb2N1bWVudC5kZXNpZ25Nb2RlID0gJ29uJzsKd2luZG93LmdldFNlbGVjdGlvbigp LnNldFBvc2l0aW9uKHRlc3QsIDApOwp3aW5kb3cuZ2V0U2VsZWN0aW9uKCkubW9kaWZ5KCdtb3Zl JywgJ2ZvcndhcmQnLCAnbGluZScpOwpkb2N1bWVudC5leGVjQ29tbWFuZCgnaW5zZXJ0VGV4dCcs IGZhbHNlLCAnUEFTUycpOwoKPC9zY3JpcHQ+CjwvYm9keT4KPC9odG1sPg== 73019 2010-11-04 17:59:50 -0700 2010-11-05 18:21:18 -0700 demo without editing command bug47806.html text/html 389 rniwa PCFET0NUWVBFIGh0bWw+IAo8aHRtbD4KPGJvZHk+CjxwcmUgaWQ9InRlc3QiIHN0eWxlPSJ3aWR0 aDogMzVleDsgaGVpZ2h0OiAxMGVtOyBvdmVyZmxvdzogc2Nyb2xsOyI+CllvdSBzaG91bGQgc2Vl ICdQQVNTJyBiZWxvdzogLS0tLS0tLS0tLTxicj48YnI+IAo8L3ByZT4gCjxzY3JpcHQ+Cgp3aW5k b3cuZ2V0U2VsZWN0aW9uKCkuc2V0UG9zaXRpb24odGVzdCwgMCk7CndpbmRvdy5nZXRTZWxlY3Rp b24oKS5tb2RpZnkoJ21vdmUnLCAnZm9yd2FyZCcsICdsaW5lJyk7CnRlc3QuaW5zZXJ0QmVmb3Jl KGRvY3VtZW50LmNyZWF0ZVRleHROb2RlKCdoZWxsbycpICwgZG9jdW1lbnQuZ2V0RWxlbWVudHNC eVRhZ05hbWUoJ2JyJylbMV0pOwoKPC9zY3JpcHQ+CjwvYm9keT4KPC9odG1sPgo= 73115 2010-11-05 14:05:57 -0700 2010-11-05 18:21:18 -0700 Test case using a timeout 47806.html text/html 322 leviw CjwhRE9DVFlQRSBodG1sPiAKPGh0bWw+IAo8Ym9keT4gCjxwcmUgaWQ9InRlc3QiIHN0eWxlPSJ3 aWR0aDogMzVleDsgaGVpZ2h0OiAxMGVtOyBvdmVyZmxvdzogc2Nyb2xsOyI+WW91IHNob3VsZCBz ZWUgJ1BBU1MnIGJlbG93OiAtLS0tLS0tLS0tPGJyPjxicj4gCjwvcHJlPiAKPHNjcmlwdD4gCgpz ZXRUaW1lb3V0KGZ1bmN0aW9uKCkge3Rlc3QuaW5zZXJ0QmVmb3JlKGRvY3VtZW50LmNyZWF0ZVRl eHROb2RlKCdoZWxsbycpICwgZG9jdW1lbnQuZ2V0RWxlbWVudHNCeVRhZ05hbWUoJ2JyJylbMV0p O30sIDEwKTsKCjwvc2NyaXB0PiAKPC9ib2R5PiAKPC9odG1sPg== 73154 2010-11-05 18:21:18 -0700 2010-11-05 18:21:18 -0700 reduced slightly more pre_appendtextnode.html text/html 279 jamesr PCFET0NUWVBFIGh0bWw+IAo8aHRtbD4KPGJvZHk+IAo8cHJlIGlkPSJ0ZXN0IiBzdHlsZT0id2lk dGg6IDM1ZXg7Ij5Zb3Ugc2hvdWxkIHNlZSAnUEFTUycgYmVsb3c6IC0tLS0tLS0tLS08YnI+PGJy PiAKPC9wcmU+IAo8c2NyaXB0PiAKZG9jdW1lbnQuYm9keS5vZmZzZXRUb3A7CnRlc3QuaW5zZXJ0 QmVmb3JlKGRvY3VtZW50LmNyZWF0ZVRleHROb2RlKCdQQVNTJykgLCBkb2N1bWVudC5nZXRFbGVt ZW50c0J5VGFnTmFtZSgnYnInKVsxXSk7Cjwvc2NyaXB0Pgo8L2JvZHk+CjwvaHRtbD4K 89033 2011-04-11 11:14:34 -0700 2011-04-11 11:21:20 -0700 adds a regression test bug-47806-20110411111433.patch text/plain 2456 rniwa SW5kZXg6IExheW91dFRlc3RzL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBMYXlvdXRUZXN0cy9D aGFuZ2VMb2cJKHJldmlzaW9uIDgzNDUyKQorKysgTGF5b3V0VGVzdHMvQ2hhbmdlTG9nCSh3b3Jr aW5nIGNvcHkpCkBAIC0xLDMgKzEsMTYgQEAKKzIwMTEtMDQtMTEgIFJ5b3N1a2UgTml3YSAgPHJu aXdhQHdlYmtpdC5vcmc+CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisK KyAgICAgICAgVGV4dCBpbnNlcnRlZCBhdCB0aGUgY29sbGFwc2VkIHNlbGVjdGlvbiBiZXR3ZWVu IHR3byBCUnMgZm9sbG93aW5nIGEgbm9uLXdyYXBwaW5nIHRleHQgdGhhdCBmb3JjZXMgb3ZlcmZs b3cKKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTQ3ODA2 CisKKyAgICAgICAgQWRkIGEgcmVncmVzc2lvbiB0ZXN0IHNpbmNlIHRoaXMgYnVnIGRvZXMgbm90 IHJlcHJvZHVjZSBhbnltb3JlLgorICAgICAgICBUaGUgdGVzdCBpcyBjby1hdXRob3JlZCBieSBK YW1lcyBSb2JpbnNvbiBhbmQgTGV2aSBXZWludHJhdWIuCisKKyAgICAgICAgKiBmYXN0L3RleHQv dGV4dC1iZXR3ZWVuLXR3by1icnMtaW4tbm93cmFwLW92ZXJmbG93LWV4cGVjdGVkLnR4dDogQWRk ZWQuCisgICAgICAgICogZmFzdC90ZXh0L3RleHQtYmV0d2Vlbi10d28tYnJzLWluLW5vd3JhcC1v dmVyZmxvdy5odG1sOiBBZGRlZC4KKwogMjAxMS0wNC0xMSAgTWFyaW8gU2FuY2hleiBQcmFkYSAg PG1zYW5jaGV6QGlnYWxpYS5jb20+CiAKICAgICAgICAgUmV2aWV3ZWQgYnkgQ2hyaXMgRmxlaXph Y2guCkluZGV4OiBMYXlvdXRUZXN0cy9mYXN0L3RleHQvdGV4dC1iZXR3ZWVuLXR3by1icnMtaW4t bm93cmFwLW92ZXJmbG93LWV4cGVjdGVkLnR4dAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBMYXlvdXRUZXN0cy9m YXN0L3RleHQvdGV4dC1iZXR3ZWVuLXR3by1icnMtaW4tbm93cmFwLW92ZXJmbG93LWV4cGVjdGVk LnR4dAkocmV2aXNpb24gMCkKKysrIExheW91dFRlc3RzL2Zhc3QvdGV4dC90ZXh0LWJldHdlZW4t dHdvLWJycy1pbi1ub3dyYXAtb3ZlcmZsb3ctZXhwZWN0ZWQudHh0CShyZXZpc2lvbiAwKQpAQCAt MCwwICsxLDMgQEAKK1RoaXMgdGVzdCBlbnN1cmVzIFdlYktpdCByZW5kZXJzIHRleHQgbm9kZSBi ZXR3ZWVuIHR3byBCUiBlbGVtZW50cyBpbiBhIHByZSB3aGVuIGluc2VydGVkIGJ5IGEgc2NyaXB0 IGltbWVkaWF0ZWx5IGFmdGVyIHRyaWdnZXJpbmcgYSBsYXlvdXQuIFlvdSBzaG91bGQgc2VlIFBB U1MgYmVsb3c6CisKK1BBU1MKSW5kZXg6IExheW91dFRlc3RzL2Zhc3QvdGV4dC90ZXh0LWJldHdl ZW4tdHdvLWJycy1pbi1ub3dyYXAtb3ZlcmZsb3cuaHRtbAo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBMYXlvdXRU ZXN0cy9mYXN0L3RleHQvdGV4dC1iZXR3ZWVuLXR3by1icnMtaW4tbm93cmFwLW92ZXJmbG93Lmh0 bWwJKHJldmlzaW9uIDApCisrKyBMYXlvdXRUZXN0cy9mYXN0L3RleHQvdGV4dC1iZXR3ZWVuLXR3 by1icnMtaW4tbm93cmFwLW92ZXJmbG93Lmh0bWwJKHJldmlzaW9uIDApCkBAIC0wLDAgKzEsMjQg QEAKKzwhRE9DVFlQRSBodG1sPiAKKzxodG1sPgorPGJvZHk+IAorPHA+VGhpcyB0ZXN0IGVuc3Vy ZXMgV2ViS2l0IHJlbmRlcnMgdGV4dCBub2RlIGJldHdlZW4gdHdvIEJSIGVsZW1lbnRzIGluIGEg cHJlIHdoZW4gaW5zZXJ0ZWQgYnkgYSBzY3JpcHQgaW1tZWRpYXRlbHkgYWZ0ZXIgdHJpZ2dlcmlu ZyBhIGxheW91dC4gWW91IHNob3VsZCBzZWUgUEFTUyBiZWxvdzo8L3A+Cis8cHJlIGlkPSJ0ZXN0 IiBzdHlsZT0id2lkdGg6IDEwZXg7Ij4tLS0tLS0tLS0tIC0tLS0tPGJyPjxicj48L3ByZT4gCis8 c2NyaXB0PiAKKworZG9jdW1lbnQuYm9keS5vZmZzZXRUb3A7CisKK3ZhciB0ZXh0ID0gZG9jdW1l bnQuY3JlYXRlVGV4dE5vZGUoJ3RleHQnKTsKK3ZhciBzcGFuID0gZG9jdW1lbnQuY3JlYXRlRWxl bWVudCgnc3BhbicpOworc3Bhbi5hcHBlbmRDaGlsZCh0ZXh0KTsKK3Rlc3QuaW5zZXJ0QmVmb3Jl KHNwYW4sIGRvY3VtZW50LmdldEVsZW1lbnRzQnlUYWdOYW1lKCdicicpWzFdKTsKKwordmFyIHBh c3NlZCA9IHNwYW4ub2Zmc2V0SGVpZ2h0ID4gMCA/IHRydWUgOiBmYWxzZTsKK3Rlc3QucGFyZW50 Tm9kZS5yZW1vdmVDaGlsZCh0ZXN0KTsKKworaWYgKHdpbmRvdy5sYXlvdXRUZXN0Q29udHJvbGxl cikKKyAgICBsYXlvdXRUZXN0Q29udHJvbGxlci5kdW1wQXNUZXh0KCk7Citkb2N1bWVudC53cml0 ZWxuKHBhc3NlZCA/ICdQQVNTJyA6ICdGQUlMJyk7CisKKzwvc2NyaXB0PgorPC9ib2R5PgorPC9o dG1sPgo=