Bug 14329 - REGRESSION: TEXTAREA - cannot drag-and-drop text at en.wikipedia.org/
Summary: REGRESSION: TEXTAREA - cannot drag-and-drop text at en.wikipedia.org/
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML Editing (show other bugs)
Version: 523.x (Safari 3)
Hardware: Mac OS X 10.4
: P1 Normal
Assignee: mitz
URL: http://en.wikipedia.org/wiki/User:Cha...
Keywords: InRadar, Regression
: 14330 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-06-23 00:02 PDT by Charles Gaudette
Modified: 2007-07-02 14:21 PDT (History)
4 users (show)

See Also:


Attachments
Patch, including pixel test and change log (18.10 KB, patch)
2007-06-23 05:23 PDT, mitz
oliver: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Charles Gaudette 2007-06-23 00:02:54 PDT
My initial try to reduce this failed, so I'm submitting in this slightly unorthodox way because I may not have the time to reduce (successfully).

STEPS:
(1) http://en.wikipedia.org/wiki/User:Charles_Gaudette/Tiffany
(2) open an "edit this page" view
(3) scroll the textarea to the comment, "TRY DRAGGING "1919" ANYWHERE"
(4) select "1919", try drag and drop inside the textarea

ALSO NOTE:
- above the comment point in Step #3 the drag-and-drop feature works
- the point at which drag-and-drop text stops working has not yet been tracked down
- the point at which drag-and-drop text stops working may not be static!
Comment 1 Alexey Proskuryakov 2007-06-23 01:03:15 PDT
I'm getting an assertion failure:

ASSERTION FAILED: Uncaught exception - Can't cache image
0
(/Users/ap/WebKit/WebCore/platform/mac/BlockExceptions.mm:36 ReportBlockedObjCException)
Comment 2 mitz 2007-06-23 02:25:20 PDT
If you scroll only by a few pixels you see that the drag image is present by clipped by the number of pixels you scrolled.
Comment 3 mitz 2007-06-23 05:23:10 PDT
Created attachment 15196 [details]
Patch, including pixel test and change log

It is somewhat unfortunate that the column adjustment needs to be done in selectionRect() for the non-clipped case, but the way absolutePosition() works I couldn't think of a way to avoid that.
Comment 4 Oliver Hunt 2007-06-25 23:01:56 PDT
Comment on attachment 15196 [details]
Patch, including pixel test and change log

Patch looks good, only thing i'll say is that you should make the layout test be text only if possible.  I can't immediately see why a pixel dump would be necessary in this case.
Comment 5 mitz 2007-06-25 23:09:07 PDT
(In reply to comment #4)
> (From update of attachment 15196 [details] [edit])
> Patch looks good, only thing i'll say is that you should make the layout test
> be text only if possible.  I can't immediately see why a pixel dump would be
> necessary in this case.
> 

I don't know of any way that selection rects come into play other than in rendering. What am I missing?
Comment 6 Oliver Hunt 2007-06-26 12:09:57 PDT
Indeed you're right -- no way to verify it without the damned pixel test :-/
Comment 7 Mark Rowe (bdash) 2007-06-26 21:46:58 PDT
Landed in r23809.
Comment 8 mitz 2007-06-30 13:03:43 PDT
*** Bug 14330 has been marked as a duplicate of this bug. ***
Comment 9 Stephanie Lewis 2007-07-02 14:21:08 PDT
From the duplicate:

<rdar://problem/5290118>