Closed Bug 614397 Opened 9 years ago Closed 9 years ago

Drag feedback image not shown for position:absolute element

Categories

(Core :: DOM: Drag & Drop, defect, P2)

x86
Windows XP
defect

Tracking

()

RESOLVED FIXED
mozilla2.0b8

People

(Reporter: Yos.T.zz, Assigned: bzbarsky)

References

Details

(Keywords: testcase)

Attachments

(2 files, 3 obsolete files)

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.
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.
Duplicate of this bug: 614417
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).
Severity: minor → normal
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression, testcase
Version: unspecified → Trunk
Disregard Comment 3. See Bug 614397 Comment 3 why.
This not a Regression against Firefox 3.6.x (or 3.5 even) ....
Keywords: regression
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.
I have no idea how to write a test for this....
Assignee: nobody → bzbarsky
Flags: in-testsuite?
Priority: -- → P2
Whiteboard: [need review]
Looks good but I think we should have a method nsDisplayListBuilder::ShouldDescendInto(nsIFrame* aFrame) which encapsulates the state bit check and the GetIncludeAllOutOfFlows check).
Attachment #495340 - Attachment is obsolete: true
Attachment #495340 - Flags: review?(roc)
Attached patch With that change (obsolete) — Splinter Review
Attachment #495495 - Flags: review?(roc)
Attachment #495495 - Attachment is obsolete: true
Attachment #495495 - Flags: review?(roc)
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.
Attachment #495567 - Flags: review?(roc) → review+
Attachment #495567 - Attachment is obsolete: true
Whiteboard: [need review] → [need approval]
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.
Attachment #495593 - Flags: approval2.0?
Comment on attachment 495593 [details] [diff] [review]
With all comments addressed

Hmm, why did we work on this instead of a blocker? :-)
Attachment #495593 - Flags: approval2.0? → approval2.0+
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.  ;)
Whiteboard: [need approval] → [need landing]
Pushed http://hg.mozilla.org/mozilla-central/rev/36a059e90495
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Whiteboard: [need landing]
Target Milestone: --- → mozilla2.0b8
You need to log in before you can comment on or make changes to this bug.