Open Bug 467297 Opened 11 years ago Updated 4 years ago

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

Categories

(Core :: Drag and Drop, defect, trivial)

defect
Not set
trivial

Tracking

()

People

(Reporter: kengruven, Unassigned)

References

Details

Attachments

(2 files)

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...
Try (a) selecting and dragging just "hello", and (b) select-all on the page and dragging the whole table.
Blocks: 435293
Component: General → Drag and Drop
OS: Mac OS X → All
Product: Firefox → Core
QA Contact: general → drag-drop
Hardware: Macintosh → All
Version: unspecified → Trunk
I can reproduce the issue (on Windows XP), so confirming.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
(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
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.
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.
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.
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.)
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.
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.
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.
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.
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.
See Also: → 1260220
You need to log in before you can comment on or make changes to this bug.