Closed Bug 614397 Opened 11 years ago Closed 11 years ago
Drag feedback image not shown for position:absolute element
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:220.127.116.11) Gecko/20101026 Firefox/3.6.12 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:18.104.22.168) 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.
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).
Disregard Comment 3. See Bug 614397 Comment 3 why. This not a Regression against Firefox 3.6.x (or 3.5 even) ....
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
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).
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]
Status: NEW → RESOLVED
Closed: 11 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.