474616 - CSS: Overflow:auto caused Drag Drop issue in (Only) Mac FF3 with Prototype JS

Status: RESOLVED WORKSFORME

(Core :: Widget: Cocoa, defect, P5)

Description

[Gary Levitt]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.5) Gecko/2008120121 Firefox/3.0.5
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.5) Gecko/2008120121 Firefox/3.0.5

When attempting to drag and drop an image from the sidebar that has overflow:auto applied in the css, Firefox gets stuck on the drag procedure. All other environments like Saf, IE6/7, FF3(PC), FF2(Mac and PC) work perfectly. It's just FF3 on Mac that has this issue.

Reproducible: Always

Steps to Reproduce:
1.Click "Compose"
2.Upload an Image
3.Try drag it over.
Actual Results:  
Image gets caught inside the sidebar.

Expected Results:  
Image should drag over with a smooth movement.

This is not likely to be our code causing the issue.

Comment 1

[Nochum Sossonko [:Natch]]

Can you provide a minimal test case. Are there any errors in the console?

Comment 2

[Gary Levitt]

(In reply to comment #1)
> Can you provide a minimal test case. Are there any errors in the console?

Hey,
This might be too complex for a simple test case, but if it helps you can have a look while we drum something up
http://www.eternal.co.za/demos/mimi/

That's a single page demo that doesn't require a user to create an acct.

There are no console errors.

Comment 3

[Gary Levitt]

The line of CSS with the Overflow:auto is:

#image_list ul {
	height: 300px;
	overflow: auto;
	width: 140px;
	margin:4px 0px 4px 4px;
}

Comment 4

[Nochum Sossonko [:Natch]]

Can you set javscript.options.showInConsole (in about:config) to true and then check.

Henrik, can you test this on Mac?

Comment 5

[Gary Levitt]

Hey guys,
I set javscript.options.showInConsole (in about:config) to true, and I'm not seeing errors as far as I can tell.

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+2]]

I can see the same behavior. Let's mark it as new and see that we can get more information. Gary, I'll attach a minimized testcase for this issue. It would be great if you will find the time to remove all the unnecessary js scripts. The best thing would be to only have one file but I don't think that it will be possible here. So please reduce the amount of lines as much as you can. Thanks!

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Attachment: Testcase

Still needs to get minimized...

Comment 8

[Gary Levitt]

Hey guys,
I've just spent some time auditing the JS here and although there's not very much to strip away because of the Proto library that's sitting on top of everything, I have some insight into the way we're dragging.

What Tobie (Tobie Langel, from Prototype who is responsible for the JS here) is trying to do, is he's waiting for a mousedown, THEN cloning the object, creating a draggable, and then activating it. He is cloning the image and the new copy is then image is created and dragged. 

He's also doing something funky with absolutizing the container and then fixing it after the drop... but only in FF. 

Since everything is tied into the Protoype JS, and I'm not a good JS coder like Tobie who built this Drag feature, I'm having trouble minimizing it further than Henrik so kindly has done.

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+2]]

As what I can see is that the start of a drag action clones the image but the new one stuck inside the sidebar until you release the mouse button. Now without a button pressed the image can be positioned. Doing a parallel test on XP doesn't show this problem. So a widget problem?

Comment 10

[Steven Michaud [:smichaud] (Retired)]

Henrik, this doesn't happen on the 1.8 branch, so it isn't a Widget : Mac bug :-)

Comment 11

[Steven Michaud [:smichaud] (Retired)]

On the face of it, it looks like something isn't receiving a mouse-up event that should be receiving one.

Comment 12

[Steven Michaud [:smichaud] (Retired)]

Or maybe some kind of drag event isn't being sent/received.

Comment 13

[Steven Michaud [:smichaud] (Retired)]

> Or maybe some kind of drag event isn't being sent/received.

No, because this bug can happen without any dragging at all.

Comment 14

[Steven Michaud [:smichaud] (Retired)]

Henrik, it'd be really nice if you could find a regression range for this.

Comment 15

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Huh, that's an really old regression. Luckily I was able to get the range. The following days no builds are available on OS X. Ok, so this regressed between the following builds:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a1) Gecko/20060928 Minefield/3.0a1

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a1) Gecko/20060929 Minefield/3.0a1

Checkins: http://tinyurl.com/ctyqkw

I highly suspect bug 326469. Means the switch from Carbon to Cocoa.

Comment 16

[Martijn Wargers (dead)]

Attachment: testcase

I was finally able to get a testcase for this. It turns out that the mouseup event is somehow eaten when the parent container changes into an absolute positioned element onmousedown.

Comment 17

[Josh Aas]

This is an old regression, it isn't clear to me that it affects enough people for us to block on it. wanted1.9.1+

Comment 18

[Sylvestre Ledru [:Sylvestre]]

Decreasing the priority as no update for the last 2 years on this bug.
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage 
about the priority meaning.

Comment 19

[Stephen A Pohl [:spohl]]

This appears to be fixed in current builds. Please reopen if this continues to be an issue.