467297 - Drag n drop of a transformed element shows the un-transformed element, unless you've selected other things, too

Status: NEW

(Core :: DOM: Copy & Paste and Drag & Drop, defect)

Description

[Ken Harris]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b1) Gecko/20081007 Firefox/3.1b1
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b1) Gecko/20081007 Firefox/3.1b1

I have a table with a -moz-transform'd cell, and some normal (untransformed) cells.  If I select the entire table (e.g., with cmd-A) and drag it, the ghost image looks just like the entire table (i.e., transform applied correctly).  But if I select just the transform cell, the ghost image looks like the element but without the transform applied.

Reproducible: Always

Steps to Reproduce:
1. Select the entire table, and drag
2. compare:
3. Select just a transformed cell, and drag
Actual Results:  
When dragging a -moz-transform'd element, it shows the untransformed element as the ghost image -- unless I'm dragging something which *contains* that element, in which case it is transformed correctly.

Expected Results:  
The ghost image should look just like it appears on the page, regardless of how I'm dragging it.

Even stranger, if you select the text of all 3 cells (but not the entire table itself) and drag, the ghost image contains only the untransformed cells.

I don't know the official terminology for this, so it may well be a dupe that I don't know how to search for in bugzilla.

Testcase coming...

Comment 1

[Ken Harris]

Attachment: Table with transformed elements -- try dragging "hello"

Try (a) selecting and dragging just "hello", and (b) select-all on the page and dragging the whole table.

Comment 2

[Ria Klaassen (not reading all bugmail)]

I can reproduce the issue (on Windows XP), so confirming.

Comment 3

[Neil Deakin]

Yes, this is because these are paint effects applied by an ancestor after the regular painting which aren't being done when painting just the child node needed for dragging.  Parent nodes with opacity (and filter effects I assue) have the same issue.

We could do them I guess, but I suspect getting the ancestors that would apply is harder.

Comment 4

[Daniel Holbert [:dholbert]]

(In reply to comment #0)
> unless I'm dragging something which *contains* that element,
> in which case it is transformed correctly.

One refinement of this point:
 - If I select-all with Ctrl-A, then yes, "hello" is transformed correctly
 - BUT: if I try to select multiple items in any other way, then I don't see "hello" at all.
  -- E.g. if I click to the right of the table, drag mouse to left of the table, and release, and then I try to drag the resulting selection, "hello" is missing in the dragged chunk.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20081129 Minefield/3.1b3pre

Comment 5

[Daniel Holbert [:dholbert]]

Actually, I just filed the issue described in comment 4 as bug 467390, because that seems like a different problem from what's described in this bug.

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I'm not convinced this is a bug. When you drag and drop a descendant of a transformed element, you're taking it out that context, so it seems logical to me that the transform would not be shown. Ditto for opacity, filters, clipping and other effects.

Then again, I can see how it could be confusing in some situations. So I dunno.

Comment 7

[Ken Harris]

The relevant question to my mind is: would/could any drop-targets see and interpret the transform?  If the answer is "no, we strip it", then I agree it's not a bug.  However, if you can drag-n-drop some sideways text, which turns horizontal for the duration of the drag, and then flips sideways again after the drop, that seems wrong.

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

What is "dragged and dropped" is just the selected HTML. No information from ancestors is transferred. So that argues for not showing ancestor effects such as transforms.

(Although stylesheets from the source document are also not transferred, yet we render the drag-drop image using those styles.)

Comment 9

[Ken Harris]

I ran across a similar case just now.  If you have some text which is "text-transform: uppercase" in CSS, it looks uppercase, and the ghost-image you drag is uppercase, but what actually gets dropped is the original case (same as copy-paste).

I'm not sure if that's a new bug, or an argument for or against changing this one's behavior.  But Firefox's behavior with these drag-n-drop ghost-images is not entirely consistent.

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

In that case, the text inherits text-transform style while it's in the original document, so it really is 'text-transform:uppercase' until you move it into the new document, where those styles do not apply. But I can see how it looks inconsistent.

I'm still not convinced it's a serious problem though.

Comment 11

[Daniel Holbert [:dholbert]]

With my mozilla-central nightly, this bug's testcase is now broken in one additional way -- the characters within the rotated string are no longer individually rotated until a portion of the string is selected.  I filed bug 518172 on this separate issue.

Comment 12

[Jonathan Kew [:jfkthame]]

Just ran across this when I was preparing to file a similar bug... ISTM that the current behavior is inconsistent and does not meet user expectations. When I select some portion of a page, and begin to drag the selected data, my expectation is that the drag image should be a "ghost" of the data exactly as displayed in the source location; it's like I'm dragging a tracing of it away from its original location.

When this data is dropped into a different context, it's true that it may end up rendered quite differently - e.g. it might be text that gets wrapped to a different line width, or it may inherit other styling from its new environment. But for the purpose of the drag image, we have to choose *some* way to present the data visually, even though we don't know how it will appear once it lands in the destination - the only reasonable choice (IMO) is that we render it in its source form for this purpose. It's not too surprising if data gets restyled by its new environment when I drop it, so that what finally appears at the destination does not look the same as the original and the drag image; but is _is_ surprising to start dragging some selected data and not have the drag image match the source from which it's being dragged.

Comment 13

[Jonathan Kew [:jfkthame]]

Attachment: screenshot of dragging some transformed text

This shows a simple example of the problem - in the screenshot, I am just beginning to drag the selected word "Hello" from the transformed <div>, but the drag image that appears (at the top left of the window) is untransformed. IMO this is a bug and provides a poor user experience.

Comment 14

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, 4 years untouched DOM/Storage bugs' priority.

If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.

Comment 16

[Emilio Cobos Álvarez (:emilio)]

Relevant code is PresShell::PaintRangePaintInfo and so on (bug 941356 added code and a TODO which is probably related). This code is not super-well tested so it probably deserves a fair amount of manual testing...