614397 - Drag feedback image not shown for position:absolute element

Status: RESOLVED FIXED

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

Description

[Joris]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12

When dragging a node with a position:absolute style the drag feedback image is not shown most of the time.
A strange exception to this is when the dragable element is directly followed by an element with the -moz-transform: rotate style (the rotation must NOT be 0 or 360 deg).
Also position:relative works fine with drag feedback image.

Reproducible: Always

Steps to Reproduce:
1.Open a page with a absolute positioned dragable element
2.drag it.
3.
Actual Results:  
No feedback image

Expected Results:  
feedback image

I'll attach a html file to demonstrate.

Comment 1

[Joris]

Attachment: html file demonstrating the problem

Open the html file.
As it is the 'Absolute' square does not display a drag feedback image, the 'Relative' does.

Some things to try:
1) Uncomment the 'id="workaround"' element. Now a feedback image is displayed as normal.
2) Change the style of the 'id="workaround"' element to 'style="-moz-transform: rotate(0deg);"'. No feedback image.
3) Comment out the id="dragObject2" element. Feedback image shows.

Comment 3

[(mostly gone) XtC4UaLL [:xtc4uall]]

from Bug 614417 Comment 0:

Regressed within:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a4fea9526b7b&tochange=1a107c990c89
=> Candidate Bugs: Bug 574596/Bug 556432

Tested on WinXP using Build built from
http://hg.mozilla.org/mozilla-central/rev/4b9ba5049e66

Works as expected on Google Chrome 9.0.583.0 (and Fx 3.6.x, of course).

Comment 4

[(mostly gone) XtC4UaLL [:xtc4uall]]

Disregard Comment 3. See Bug 614397 Comment 3 why.
This not a Regression against Firefox 3.6.x (or 3.5 even) ....

Comment 5

[Boris Zbarsky [:bzbarsky]]

So the issue is that when we build the display list for the selection in this case we use the <div>'s frame as the place to stop building.  And the abs pos content is not a descendant of this, of course.  So we never mark the abs pos frame with a dirty rect property, and then the BuildDisplayListForChild() call when the child is a placeholder decides the dirty rect doesn't intersect the frame's rect and optimizes away traversing down into the abs pos frame.

If I change PresShell::CreateRangePaintInfo to always use rootFrame as the place to start building the display list, the problem goes away.

It seems like when we're doing paint-for-drag we should always do the descent into placeholders that we do for the SetSelectedFramesOnly() case.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Attachment: Always descend through all placeholders while doing any sort of selection display list.

Comment 7

[Boris Zbarsky [:bzbarsky]]

I have no idea how to write a test for this....

Comment 8

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

Looks good but I think we should have a method nsDisplayListBuilder::ShouldDescendInto(nsIFrame* aFrame) which encapsulates the state bit check and the GetIncludeAllOutOfFlows check).

Comment 9

[Boris Zbarsky [:bzbarsky]]

Attachment: With that change

Comment 10

[Boris Zbarsky [:bzbarsky]]

Attachment: Always descend through all placeholders while doing any sort of selection display list.

Comment 11

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

Comment on attachment 495567 [details] [diff] [review]
Always descend through all placeholders while doing any sort of selection display list.

ShouldDescendIntoAllChildren isn't named right. It's really ShouldDescendIntoFrame. r+ with that.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Attachment: With all comments addressed

Comment 13

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 495593 [details] [diff] [review]
With all comments addressed

This is a safe fix that makes drag feedback work right when out-of-flows are involved.

Comment 14

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

Comment on attachment 495593 [details] [diff] [review]
With all comments addressed

Hmm, why did we work on this instead of a blocker? :-)

Comment 15

[Boris Zbarsky [:bzbarsky]]

Because if you look on the date stamps of when I was working on this, I was too out of it to work on anything that really needed thought...  Comment 5 was 3:30am local time.  ;)

Comment 16

[Boris Zbarsky [:bzbarsky]]

Pushed http://hg.mozilla.org/mozilla-central/rev/36a059e90495